host=gerrit.onap.org
port=29418
project=doc.git
+defaultbranch=beijing
# General information about the project.
project = u''
-copyright = u'2017 ONAP. Licensed under Creative Commons Attribution 4.0 International License'
+copyright = u'2018 ONAP. Licensed under Creative Commons Attribution 4.0 International License'
author = u'Open Network Automation Platform'
# |version| and |release|, also used in various other places throughout the
# built documents.
# The short X.Y version.
-version = 'master branch'
+version = '2.0.0'
# The full version, including alpha/beta/rc tags.
-release = 'master branch'
+release = 'Beijing'
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. This work is licensed under a Creative Commons Attribution 4.0
+.. International License. http://creativecommons.org/licenses/by/4.0
Addendum
========
See http://sphinx-doc.org/rest.html .
**Hint:**
-You can add html content that only appears in html output by using the
+You can add html content that only appears in html output by using the
'only' directive with build type
('html' and 'singlehtml') for an ONAP document. But, this is not encouraged.
.. code-block:: rst
- Some content that requires an :index:`index`.
+ Some content that requires an :index:`index`.
or
The verify job name is **doc-{stream}-verify-rtd**
-Proposed changes in files in any repository with the path
+Proposed changes in files in any repository with top level docs folder
+in the repository and RST files in below this folder
+will be verified by this job as part of a gerrit code review.
-.. bash
+.. Important::
+ The contributing author and every reviewer on a gerrit code review
+ should always review the Jenkins log before approving and merging a
+ change. The log review should include:
- docs/**/*.rst
-
-will be verified by this job prior to a gerrit code review.
-Please check the Jenkins log carefully for warnings.
-You can improve your document even if the verify job succeeded.
+ * Using a browser or other editor to search for a pattern in the
+ *console log* that matches files in the patch set. This will quickly
+ identify errors and warnings that are related to the patch set and
+ repository being changed.
+
+ * Using a browser to click on the *html* folder included in the log
+ and preview how the proposed changes will look when published at
+ Read The Docs. Small changes can be easily made in the patch set.
+ UML and Graphviz defined diagrams do not currently
+ render in the verify job log, but will render at Read The Docs
+ when the change is merged.
Merge Job
+++++++++
The merge job name is **doc-{stream}-merge-rtd**.
-When a committer merges a patch that includes files matching the path described above,
-the doc project merge job will trigger an update at readthedocs.
-This might take about 15 minutes while readthedocs
-builds the documentation.
+When a committer merges a patch that includes files matching the
+path described above, the doc project merge job will trigger an
+update at readthedocs. There may be some delay after the merge job
+completes until new version appears at Read The Docs.
+
+Read The Docs URLs
+------------------
+
+When referencing versions of documentation a Read The Docs the following
+URL conventions should be used
+
+ +----------------------------------+----------------------------------------+
+ | URL | To Refer to |
+ +==================================+========================================+
+ | docs.onap.org | Most recent approved named release |
+ +----------------------------------+----------------------------------------+
+ | docs.onap.org/en/latest | Latest master branch all projects |
+ +----------------------------------+----------------------------------------+
+ | docs.onap.org/en/*named release* | An approved name release eg. amsterdam |
+ +----------------------------------+----------------------------------------+
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. This work is licensed under a Creative Commons Attribution 4.0
+.. International License. http://creativecommons.org/licenses/by/4.0
+.. Copyright 2017 AT&T Intellectual Property. All rights reserved.
.. _converting-to-rst:
Installing pandoc
-----------------
-Pandoc is a powerful document-transformation utility. We'll use it to do simple conversions, but it is capable of much more. Visit the `pandoc website <http://pandoc.org/installing.html>`_ for installation instructions for your platform.
+Pandoc is a powerful document-transformation utility. We'll use it to
+do simple conversions, but it is capable of much more. Visit
+the `pandoc website <http://pandoc.org/installing.html>`_ for
+installation instructions for your platform.
Converting
----------
-Using a terminal, navigate to the directory containing the documents you wish to convert. Next, issue the following command for each file you'd like to convert:
+Using a terminal, navigate to the directory containing the documents
+you wish to convert. Next, issue the following command for each file
+you'd like to convert:
:code:`pandoc -s --toc -f <from format> -t rst myfile.<from format>`
Fixing the converted document
-----------------------------
-How much you'll need to fix the converted document depends on which file format you're converting from. Here are a couple of things to watch out for:
+How much you'll need to fix the converted document depends on which file
+format you're converting from. Here are a couple of things to watch out
+for:
1. Multi-line titles need to be converted to single line
2. Standalone "**" characters
Web-based
~~~~~~~~~
-`rst.ninjs.org <http://rst.ninjs.org>`_ has an excellent RST previewing tool that highlights RST errors with line numbers.
-
-
-
+`rst.ninjs.org <http://rst.ninjs.org>`_ has an excellent RST previewing
+tool that highlights RST errors with line numbers.
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-
+.. This work is licensed under a Creative Commons Attribution 4.0
+.. International License. http://creativecommons.org/licenses/by/4.0
+.. Copyright 2017 AT&T Intellectual Property. All rights reserved.
Introduction
============
This guide describes how to create documentation for the Open Network
-Automation Platform (ONAP). ONAP projects create a variety of
-content depending on the nature of the project. For example projects delivering
-a platform component may have different types of content than
+Automation Platform (ONAP). ONAP projects create a variety of
+content depending on the nature of the project. For example projects
+delivering a platform component may have different types of content than
a project that creates libraries for a software development kit.
-The content from each project may be used together as a reference for that project
-and/or be used in documents are tailored to a specific user audience and
-task they are performing.
+The content from each project may be used together as a reference for
+that project and/or be used in documents are tailored to a specific
+user audience and task they are performing.
-Much of the content in this document is derived from similar
-documentation processes used in other Linux Foundation
+Much of the content in this document is derived from similar
+documentation processes used in other Linux Foundation
Projects including OPNFV and Open Daylight.
Authors create source for documents in reStructured Text (RST) that is
rendered to HTML and PDF and published on Readthedocs.io.
-The developer Wiki or other web sites can reference these rendered
+The developer Wiki or other web sites can reference these rendered
documents directly allowing projects to easily maintain current release
documentation.
Why reStructuredText/Sphinx?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-In the past, standard documentation methods included ad-hoc Word documents, PDFs,
-poorly organized Wikis, and other, often closed, tools like Adobe FrameMaker.
-The rise of DevOps, Agile, and Continuous Integration, however, created a paradigm
-shift for those who care about documentation because:
+In the past, standard documentation methods included ad-hoc Word documents,
+PDFs, poorly organized Wikis, and other, often closed, tools like
+Adobe FrameMaker. The rise of DevOps, Agile, and Continuous Integration,
+however, created a paradigm shift for those who care about documentation
+because:
-1. Documentation must be tightly coupled with code/product releases. In many cases,
-particularly with open-source products, many different versions of the same code
-can be installed in various production environments. DevOps personnel must have
-access to the correct version of documentation.
+1. Documentation must be tightly coupled with code/product releases.
+ In many cases, particularly with open-source products, many different
+ versions of the same code can be installed in various production
+ environments. DevOps personnel must have access to the correct version
+ of documentation.
2. Resources are often tight, volunteers scarce. With a large software base
-like ONAP, a small team of technical writers, even if they are also developers,
-cannot keep up with a constantly changing, large code base. Therefore, those closest
-to the code should document it as best they can, and let professional writers edit for
-style, grammar, and consistency.
+ like ONAP, a small team of technical writers, even if they are also
+ developers, cannot keep up with a constantly changing, large code base.
+ Therefore, those closest to the code should document it as best they can,
+ and let professional writers edit for style, grammar, and consistency.
-Plain-text formatting syntaxes, such as reStructuredText, Markdown, and Textile,
-are a good choice for documentation because:
+Plain-text formatting syntaxes, such as reStructuredText, Markdown,
+and Textile, are a good choice for documentation because:
a. They are editor agnostic
+
b. The source is nearly as easy to read as the rendered text
+
c. Documentation can be treated exactly as source code is (e.g. versioned,
- diff'ed, associated with commit messages that can be included in rendered docs)
+ diff'ed, associated with commit messages that can be included
+ in rendered docs)
+
d. Shallow learning curve
-The documentation team chose reStructuredText largely because of Sphinx, a Python-based
-documentation build system, which uses reStructuredText natively. In a code base
-as large as ONAP's, cross-referencing between component documentation was deemed
-critical. Sphinx and reStructuredText have built-in functionality that makes
-collating and cross-referencing component documentation easier.
+The documentation team chose reStructuredText largely because of Sphinx,
+a Python-based documentation build system, which uses reStructuredText
+natively. In a code base as large as ONAP's, cross-referencing between
+component documentation was deemed critical. Sphinx and reStructuredText
+have built-in functionality that makes collating and cross-referencing
+component documentation easier.
Which docs should go where?
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Frequently, developers ask where documentation should be created. Should they always use
-reStructuredText/Sphinx? Not necessarily. Is the wiki appropriate for anything at all? Yes.
+Frequently, developers ask where documentation should be created. Should
+they always use reStructuredText/Sphinx? Not necessarily. Is the wiki
+appropriate for anything at all? Yes.
It's really up to the development team. Here is a simple rule:
-The more tightly coupled the documentation is to a particular version of the code,
-the more likely it is that it should be stored with the code in reStructuredText.
+The more tightly coupled the documentation is to a particular version
+of the code, the more likely it is that it should be stored with the
+code in reStructuredText.
-Two examples on opposite ends of the spectrum:
+The doc team encourages component teams to store as much documentation
+as reStructuredText as possible because:
-Example 1: API documentation is often stored literally as code in the form of formatted
-comment sections. This would be an ideal choice for reStructuredText stored in a doc repo.
+1. It is easier to edit component documentation for grammar,
+ spelling, clarity, and consistency.
-Example 2: A high-level document that describes in general how a particular component interacts
-with other ONAP components with charts. The wiki would be a better choice for this.
+2. A consistent formatting syntax across components will allow
+ flexibility in producing different kinds of output.
-The doc team encourages component teams to store as much documentation as reStructuredText
-as possible because:
+3. It is easier to re-organize the documentation.
-1. The doc team can more easily edit component documentation for grammar, spelling, clarity, and consistency.
-2. A consistent formatting syntax across components will allow the doc team more flexibility in producing different kinds of output.
-3. The doc team can easily re-organize the documentation.
-4. Wiki articles tend to grow stale over time as the people who write them change positions or projects.
+4. Wiki articles tend to grow in size and not maintained making it hard
+ to find current information.
Structure
---------
-A top level master document structure is used to organize all
-documents for an ONAP release and this resides in the gerrit doc repository.
-Complete documents or guides may reside here and reference parts of
-source for documentation from other project repositories
-A starting structure is shown below and may change as content is
-integrated for each release. Other ONAP projects will provide
-content that is referenced from this structure.
-
-
+A top level master document structure is used to organize all
+documents created by ONAP projects and this resides in the gerrit doc
+repository. Complete documents or guides may reside here and
+reference parts of source for documentation from other project
+repositories. Other ONAP projects will provide content that
+is referenced from this structure.
::
- docs/
- ├── releases
- │ ├── major releases
- │ ├── projects
- │ ├── cryptographic signatures
- │ └── references
- ├── onap-developer
- │ ├── architecture
- │ ├── tutorials
- │ ├── setting up
- │ ├── developing
- │ └── documenting
- └── onap-users
- ├── vf provider
- ├── service designer
- ├── service administrator
- └── platform administrator
-
+ docs/
+ ├── guides
+ │ ├── onap-developer
+ │ │ ├── apiref
+ │ │ ├── architecture
+ │ │ ├── developing
+ │ │ ├── how-to-use-docs
+ │ │ ├── settingup
+ │ │ └── tutorials
+ │ └── onap-user
+ │ ├── onap-portal
+ │ ├── platform operations
+ │ ├── service design
+ │ ├── service deployment
+ │ ├── vnf provider
+ │ └── vnf certifier
+ ├── release
+ ├── templates
+ │ ├── collections
+ │ └── sections
+ └── use-cases
Source Files
------------
-All documentation for a project should be structured and stored
+All documentation for project repositories should be structured and stored
in or below `<your_project_repo>/docs/` directory as Restructured Text.
ONAP jenkins jobs that verify and merge documentation are triggered by
RST file changes in the top level docs directory and below.
-
-
Licensing
---------
All contributions to the ONAP project are done in accordance with the
ONAP licensing requirements. Documentation in ONAP is contributed
in accordance with the `Creative Commons 4.0 <https://creativecommons.org/licenses/by/4.0/>`_ license.
-All documentation files need to be licensed using the text below.
-The license may be applied in the first lines of all contributed RST
+All documentation files need to be licensed using the text below.
+The license may be applied in the first lines of all contributed RST
files:
.. code-block:: bash
These lines will not be rendered in the html and pdf files.
-When there are subsequent, significant contributions to a source file from a different contributor,
-a new copyright line may be appended after the last existing copyright line.
+When there are subsequent, significant contributions to a source file
+from a different contributor, a new copyright line may be appended
+after the last existing copyright line.
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. This work is licensed under a Creative Commons Attribution 4.0
+.. International License. http://creativecommons.org/licenses/by/4.0
+.. Copyright 2017 AT&T Intellectual Property. All rights reserved.
Setting Up
:width: 1000
seqdiag {
- RD [label = "Read The Docs", color =lightgreen ];
DA [label = "Doc Project\nAuthor/Committer", color=lightblue];
DR [label = "Doc Gerrit Repo" , color=pink];
PR [label = "Other Project\nGerrit Repo", color=pink ];
PA [label = "Other Project\nAuthor/Committer", color=lightblue];
- === One time setup doc project only ===
- RD -> DA [label = "Acquire Account" ];
- DA -> DR [label = "Create initial\n doc repository content"];
- DA <<-- DR [label = "Merge" ];
- RD <-- DA [label = "Connect gerrit.onap.org" ];
- === For each project repository containing document source ===
PA -> DR [label = "Add project repo as\ngit submodule" ];
DR -> DA [label = "Review & Plan to\nIntegrate Content with\nTocTree Structure" ];
DR <-- DA [label = "Vote +2/Merge" ];
PA <-- PR [label = "Merge" ];
}
-
-
-Setup doc project
------------------
-These steps are performed only once for the doc project and include:
-
-(1) creating in the doc repository an initial:
-
- - sphinx master document index
-
- - a directory structure aligned with the document structure
-
- - tests performed in jenkins verify jobs
-
- - sphinx configuration
-
-(2) establishing an account at readthedocs connected with the doc
-doc project repo in gerrit.onap.org.
-
-
Setup project repositories(s)
-----------------------------
-These steps are performed for each project repository that provides documentation.
+These steps are performed for each project repository that
+provides documentation.
First let's set two variables that will be used in the subsequent steps.
-Set reponame to the project repository you are setting up just as it appears in the
-**Project Name** column of the Gerrit projects page.
-Set lfid to your Linux Foundation identity that you use to login to gerrit or for git
-clone requests over ssh.
+Set *reponame* to the project repository you are setting up
+just as it appears in the **Project Name** column of
+the Gerrit projects page.
+Set *lfid* to your Linux Foundation identity that you use to
+login to gerrit or for git clone requests over ssh.
.. code-block:: bash
reponame=
lfid=
-The next step is to add a directory in the doc project where your project will be included as a
-submodule and at least one reference from the doc project to the documentation index in your repository.
+The next step is to add a directory in the doc project where your
+project will be included as a submodule and at least one reference
+from the doc project to the documentation index in your repository.
The following sequence will do this over ssh.
.. caution::
- If your access network restricts ssh, you will need to use equivalent git commands and
- HTTP Passwords as described `here <http://wiki.onap.org/x/X4AP>`_.
+ If your access network restricts ssh, you will need to use equivalent
+ git commands and HTTP Passwords as described `here <http://wiki.onap.org/x/X4AP>`_.
.. code-block:: bash
.. caution::
Wait for the above change to be merged before any merge to the
project repository that you have just added as a submodule.
- If the project repository added as submodule changes before the doc project merge, git may not
- automatically update the submodule reference on changes and/or the verify job will
- fail in the step below.
+ If the project repository added as submodule changes before the
+ doc project merge, git may not automatically update the submodule
+ reference on changes and/or the verify job will fail in the step below.
-The last step is to create a docs directory in your repository with an index.rst file.
-The following sequence will complete the minimum required over ssh. As you have time
-to convert or add new content you can update the index and add files under the docs folder.
+The last step is to create a docs directory in your repository with
+an index.rst file. The following sequence will complete the minimum
+required over ssh. As you have time to convert or add new content you
+can update the index and add files under the docs folder.
.. hint::
If you have additional content, you can include it by editing the
index.rst file and/or adding other files before the git commit.
- See `Templates and Examples`_ below and :ref:`converting-to-rst` for more information.
+ See `Templates and Examples`_ below and :ref:`converting-to-rst`
+ for more information.
.. code-block:: bash
a jenkins verify job, and/or published release documentation including:
- ONAP gerrit project repositories,
-- doc project repository master document index.rst, templates, configuration, and other documents
-- submodules directory where other project repositories and directories/files are referenced
+
+- doc project repository master document index.rst, templates,
+ configuration, and other documents
+
+- submodules directory where other project repositories and
+ directories/files are referenced
+
- file structure: directories (ellipses), files(boxes)
-- references: directory/files (solid edges), git submodule (dotted edges), sphinx toctree (dashed edges)
+- references: directory/files (solid edges), git submodule
+ (dotted edges), sphinx toctree (dashed edges)
.. graphviz::
}
+Branches in the DOC Project
+---------------------------
+
+The DOC project 'master' branch aggregates the 'latest' content
+from all ONAP project repositories contributing documentation into a
+single tree file structure as described in the previous section. This
+branch is continuously integrated and deployed at Read The
+Docs as the 'latest' ONAP Documentation by:
+
+* Jenkins doc-verify-rtd and doc-merge-rtd jobs triggered whenever patches on
+ contributing repositories contain rst files at or below a top level
+ 'docs' folder.
+
+* Subscription in the DOC project to changes in submodule repositories.
+ These changes appear in the DOC project as commits with title
+ 'Updated git submodules' when a change to a contributing project
+ repository is merged. No DOC project code review occurs, only a
+ submodule repository commit hash is updated to track the head of each
+ contributing master branch.
+
+For each ONAP named release the DOC project creates a branch with the
+release name. The timing of the release branch is determined by
+work needed in the DOC project to prepare the release branch and the
+amount of change unrelated to the release in the master branch.
+For example contributing projects that create named release branches
+early to begin work on the next release and/or contributing projects
+to the master that are not yet part of the named release would result
+in an earlier named release branch to cleanly separate work to stabilize
+a release from other changes in the master branch.
+
+A named release branch is integrated and deployed at Read The Docs
+as the 'named release' by aggregating content from contributing
+project repositories. A contributing project repository can
+choose one of the following for the 'named release' branch:
+
+* Remove the contributing project repository submodule and RST
+ references when not part of the named release.
+
+* Provide a commit hash or tag for the contributing project master
+ branch to be used for the life of the release branch or until a
+ request is submitted to change the commit hash or tag.
+
+* Provide the commit hash for the head of a named release branch
+ created in the contributing project repository. This option
+ may be appropriate if frequent changes are expected over the
+ life of the named release and work the same way as the continuous
+ integration and deployment described for the master branch.
+
+The decision on option for each contributing project repository
+can be made or changed before the final release is approved. The
+amount of change and expected differences between master and a
+named release branch for each repository should drive the choice of
+option and timing.
+
About GIT branches
------------------
GIT is a powerful tool allowing many actions, but without respecting some rules
-the GIT structure can be quickly ugly and unmaintainble.
+the GIT structure can be quickly hard to maintain.
Here are some conventions about GIT branches:
+
- ALWAYS create a local branch to edit or create any file. This local branch
- will be considered as a topic in Gerrit and allow contributors to work at the
- same time on the same project.
- - 1 feature = 1 branch. In the case of documentation, a new chapter or page about
- a new code feature can be considered as a 'doc feature'
- - 1 bug = 1 branch. In the case of documentation, a correction on an existing
- sentence can be considered as a 'doc bug'
+ will be considered as a topic in Gerrit and allow contributors to
+ work at the same time on the same project.
+
+ - 1 feature = 1 branch. In the case of documentation, a new chapter
+ or page about a new code feature can be considered as a 'doc feature'
+
+ - 1 bug = 1 branch. In the case of documentation, a correction on an
+ existing sentence can be considered as a 'doc bug'
+
- the master branch is considered as "unstable", containing new features that
will converge to a stable situation for the release date.
- NEVER push a new feature on a stable branch
- - Only bug correction are authorized on a stable branch using cherry pick method
+ - Only bug correction are authorized on a stable branch using
+ cherry pick method
.. image:: git_branches.png
----------------------
Templates are available that capture the kinds of information
useful for different types of projects and provide some examples of
-restructured text. We organize templates in the following way to: help authors
-understand relationships between documents; keep the user audience context in mind when writing;
-and tailor sections for different kinds of projects.
+restructured text. We organize templates in the following way to:
+
+ - help authors understand relationships between documents
+
+ - keep the user audience context in mind when writing and
-**Sections** Represent a certain type of content. A section is **provided** in a repository, to
-to describe something about the characteristics, use, capability, etc. of things in that repository.
-A section may also be **referenced** from other sections and in other repositories.
+ - tailor sections for different kinds of projects.
+
+
+**Sections** Represent a certain type of content. A section
+is **provided** in an project repository, to describe something about
+the characteristics, use, capability, etc. of things in that repository.
+A section may also be **referenced** from other sections and in
+other repositories. For example, an API specification provided in a project
+repository might be referenced to in a Platform API Reference Guide.
The notes in the beginning of each section template provide
-additional detail about what is typically covered and where there may be references to the section.
+additional detail about what is typically covered and where
+there may be references to the section.
-**Collections** Are a set of sections that are typically provided for a particular type
-of project, repository, guide, reference manual, etc.
+**Collections** Are a set of sections that are typically provided
+for a particular type of project, repository, guide, reference manual, etc.
+For example, a collection for a platform component, an SDK, etc.
-You can: browse the template *collections* and *sections* below; show source to look at the Restructured
-Text and Sphinx directives used; copy the source either from a browser window
-or by downloading the file in raw form from
+You can: browse the template *collections* and *sections* below;
+show source to look at the Restructured Text and Sphinx directives used;
+copy the source either from a browser window or by downloading the
+file in raw form from
the `gerrit doc repository <https://gerrit.onap.org/r/gitweb?p=doc.git;a=tree;f=docs/templates;/>`_ and
then add them to your repository docs folder and index.rst.
In addition to these simple templates and examples
there are many open source projects (e.g. Open Daylight, Open Stack)
-that are using Sphinx and Readthedocs where you may find examples to start with.
-Working with project teams we will continue to enhance templates here and
-capture frequently asked questions on the developer wiki question
-topic `documentation <https://wiki.onap.org/questions/topics/16384055/documentation>`_.
-
-Each project should: decide what is relevant content; determine the
-best way to create/maintain it in a CI/CD process; and work with the
-documentation team to reference content from the master index and guides.
-Consider options including filling in a template,
-identifying existing content that can be used as is or
-easily converted, and use of Sphinx directives/extensions to automatically
-generate restructured text from other source you already have.
+that are using Sphinx and Readthedocs where you may find examples
+to start with. Working with project teams we will continue to enhance
+templates here and capture frequently asked questions on the developer
+wiki question topic `documentation <https://wiki.onap.org/questions/topics/16384055/documentation>`_.
+
+Each project should:
+
+ - decide what is relevant content
+
+ - determine the best way to create/maintain it in the CI/CD process and
+
+ - work with the documentation team to reference content from the
+ master index and guides.
+
+Consider options including filling in a template, identifying existing
+content that can be used as is or easily converted, and use of Sphinx
+directives/extensions to automatically generate restructured text
+from other source you already have.
Links and References
--------------------
All Documentation
-----------------
-To build the whole documentation under doc/, follow these steps:
+To build the all documentation under doc/, follow these steps:
Install virtual environment.
.. note:: Make sure to run `tox -elocal` and not just `tox`.
-There are additional tox enviornment options for checking External URLs and Spelling.
-Use the tox environment options below and then look at the output with the Linux `more` or
-similar command for scanning for output that applies to the files you
-are validating.
+There are additional tox environment options for checking External
+URLs and Spelling. Use the tox environment options below and then
+look at the output with the Linux `more` or similar command for
+scanning for output that applies to the files you are validating.
.. code-block:: bash
-.. This work is licensed under a
- Creative Commons Attribution 4.0 International License.
+.. This work is licensed under a Creative Commons Attribution 4.0
+.. International License. http://creativecommons.org/licenses/by/4.0
Creating Documentation
======================
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. This work is licensed under a Creative Commons Attribution 4.0
+.. International License. http://creativecommons.org/licenses/by/4.0
+.. Copyright 2017 AT&T Intellectual Property. All rights reserved.
Style guide
===========
-This style guide is for ONAP documentation contributors, reviewers and committers.
+This style guide is for ONAP documentation contributors, reviewers and
+committers.
Getting started
---------------
When is documentation required?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-All ONAP project contributions should have corresponding documentation. This includes all new features and changes to features that impact users.
+All ONAP project contributions should have corresponding documentation.
+This includes all new features and changes to features that impact users.
How do I create ONAP documentation?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-ONAP documentation is written in ReStructuredText_ (an easy-to-read, what-you-see-is-what-you-get, plain text markup syntax).
-The process for creating ONAP documentation and what documents are required are described here: <<add links to Documentation process/automated tools sections>>
+ONAP documentation is written in ReStructuredText_ (an easy-to-read,
+what-you-see-is-what-you-get, plain text markup syntax). The process for
+creating ONAP documentation and what documents are required are
+described in later sections of this Developer Documentation Guide.
.. _ReStructuredText: http://docutils.sourceforge.net/rst.html
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For detailed information ReStructuredText and how to best use the format, see:
-- `ReStructured Text Primer <http://docutils.sourceforge.net/docs/user/rst/quickstart.html>`
-- `ReStructured Text Quick Reference <http://docutils.sourceforge.net/docs/user/rst/quickref.html>`
+- `ReStructured Text Primer <http://docutils.sourceforge.net/docs/user/rst/quickstart.html>`_
+- `ReStructured Text Quick Reference <http://docutils.sourceforge.net/docs/user/rst/quickref.html>`_
Writing guidelines
------------------
-Following these writing guidelines will keep ONAP documentation consistent and readable. Only a few areas are covered below, as we don't want to make it too complex. Try to keep things simple and clear, and you can't go far wrong.
+Following these writing guidelines will keep ONAP documentation
+consistent and readable. Only a few areas are covered below, as
+we don't want to make it too complex. Try to keep things simple
+and clear, and you can't go far wrong.
-Don’t get too hung up on using correct style. We’d rather have you submit good information that doesn’t conform to this guide than no information at all. ONAP’s Documentation project team will be happy to help you with the prose.
+Don’t get too hung up on using correct style. We’d rather have you
+submit good information that does not conform to this guide than no
+information at all. ONAP’s Documentation project team will be happy
+to help you with the prose.
General guidelines for all documents
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- Use standard American English and spelling
-- Use consistent terminology
+- Use consistent terminology
- Write in the active voice, using present simple tense when possible
- Write objective, professional content
- Keep sentences and paragraphs short and clear
Abbreviations and acronyms
^^^^^^^^^^^^^^^^^^^^^^^^^^
-- Write out the term the first time it appears in the document, immediately followed by the acronym or abbreviation in parenthesis. Then use the acronym in the rest of the document. In diagrams, if space allows, write out the full term.
-- Use “an” before an acronym that begins with a vowel sound when spoken aloud; use "a" before an acronym that begins with a consonant sound when spoken aloud.
+- Write out the term the first time it appears in the document,
+ immediately followed by the acronym or abbreviation in parenthesis.
+ Then use the acronym in the rest of the document. In diagrams, if
+ space allows, write out the full term.
+
+- Use “an” before an acronym that begins with a vowel sound when spoken
+ aloud; use "a" before an acronym that begins with a consonant
+ sound when spoken aloud.
+
+ Examples: an MSO component, a LAN, an L3-VPN
ONAP terms
^^^^^^^^^^
- AA&I vs AAI: AAI should be used.
-- APP-C vs APPC: APPC should be used.
+
+- APP-C vs APPC: APPC should be used.
+
- SDN-C vs SDNC: SDNC should be used.
+
- Heat vs HEAT: Both are in use. The official website uses "Heat".
+
- life cycle vs lifecycle or life-cycle: "life cycle" is preferred.
-- open source (adjective): capitalize only in titles; avoid "open-source". (Based on prevalence on the web.)
-- run-time vs. execution-time (adjective): prefer run-time. Example: "run-time logging of events"
+
+- open source (adjective): capitalize only in titles; avoid
+ "open-source". (Based on prevalence on the web.)
+
+- run-time vs. execution-time (adjective): prefer run-time.
+ Example: "run-time logging of events"
+
- run time (noun). Example: "logging of events at run time".
GUI elements
^^^^^^^^^^^^
-- In general, write menu names as they appear in the UI. For example, if a menu or item name is all caps, then write it all caps in the document.
+- In general, write menu names as they appear in the UI.
+ For example, if a menu or item name is all caps, then write
+ it all caps in the document.
Headings (Titles)
^^^^^^^^^^^^^^^^^
-- Use brief, but specific, informative titles. Titles should give context when possible.
+- Use brief, but specific, informative titles. Titles should give
+ context when possible.
+
- Use sentence-style capitalization; do not end with a period or colon.
-- Use a gerund to begin section titles. Examples: Configuring, Managing, Starting.
-- Use descriptive titles for tables and figures titles. Do not number tables or figures. Do not (in general) add titles for screen shots.
+
+- Use a gerund to begin section titles. Examples: Configuring,
+ Managing, Starting.
+
+- Use descriptive titles for tables and figures titles. Do not
+ number tables or figures. Do not (in general) add titles for screen shots.
Tasks
^^^^^
-- Start task titles with an action word. Examples: Create, Add, Validate, Update.
+- Start task titles with an action word. Examples: Create, Add,
+ Validate, Update.
+
- Use [Optional] at the beginning of an optional step.
-- Provide information on the expected outcome of a step, especially when it is not obvious.
+
+- Provide information on the expected outcome of a step, especially
+ when it is not obvious.
+
- Break down end-to-end tasks into manageable chunks.
ONAP Documentation
==================
+.. graphviz::
+
+ digraph {
+ "Under Construction" [shape=rect style=filled fillcolor=yellow]
+ "Q: What are options for including my project documentation here?\nA: See Branches in the DOC Project click here"
+ [href="http://docs.onap.org/en/latest/guides/onap-developer/how-to-use-docs/include-documentation.html#branches-in-the-doc-project"
+ shape=rect style=filled fillcolor=lightblue];
+ "Q: Where should I be making final documentation changes for Beijing?\nA: See onap-discuss topic here"
+ [href="https://lists.onap.org/pipermail/onap-discuss/2018-May/010004.html" shape=rect style=filled fillcolor=lightblue];
+ }
+
.. toctree::
:maxdepth: 2
Code Review / doc.git / commitdiff