openstack-manuals/doc/doc-contrib-guide/source/quickstart/developers.rst
Andreas Jaeger 50470925d1 Fix project-navigator links
The navigator has moved, update links.

Change-Id: Idb6f0dc09d0bea0617fa89ab80fc1fd3b196c6cc
Closes-Bug: #1791447
2018-09-09 08:04:57 +02:00

46 lines
2.3 KiB
ReStructuredText

.. _developers:
==========
Developers
==========
When you are writing a new feature for a component of OpenStack, it is
important that you also document that new feature.
This is also true if you are adding or changing configuration options,
commands, or other user-facing components.
Many of these types of changes are handled automatically by directives and
configuration generators provided by libraries such as oslo.config and
oslo.policy, and published as part of the project-specific documentation.
For more information about these automated tools, see :ref:`doc-tools`.
If you are contributing documentation to the main openstack-manuals
repository, there are a few things you can do to help your patch merge
quickly and easily:
* Contact your project's documentation `cross-project liaison
<https://wiki.openstack.org/wiki/CrossProjectLiaisons#Documentation>`_.
They can help you with finding the appropriate book to add your patch, and
the relevant people to review your patch once you have written it.
* If you are not confident in your written English skills, you can create a
patch and add a note that you are happy to have editorial assistance.
This will encourage writers to check out your patch and correct any
spelling or grammar mistakes, rather than just adding comments for you
to fix yourself.
* If you do not know which book to edit, or you are uncertain about creating
a patch, you can create a bug with source content or notes, and ask for
assistance from the docs team on finding the right location for the content.
* If you know which book you want to modify, get in contact with the
`appropriate project team
<https://www.openstack.org/software/project-navigator/openstack-components>`_ or
:doc:`subteam <../team-structure>`. They can help you determine where the
content should live, and also give you details about upcoming changes to the
architecture of those books that might affect your new documentation.
* If you are intending to make a very large change, such as an entirely
new section or chapter, or documenting a new project, the core team might
ask you to create a blueprint and specification for the change. If you are
unsure whether your change will require a blueprint or specification, ask
on the mailing list for guidance.
* Remember, you can always contact the documentation team through our mailing
list, or on IRC.