b3ba9020bd
Working from the Newton docs deliverables list from the Austin Summit: * Who should follow this guide? * Introduction of a minimal review time? * Section about contribution recommendations: what devs should contribute, review expectations of docs, expected turn-around time, etc. * How to deprecate/remove docs? * Also define which are continuous-release, versioned, etc. Change-Id: I9df39977a8e9ca81960c6ee8840e864054d9b1d2
44 lines
2.1 KiB
ReStructuredText
44 lines
2.1 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
|
|
``openstack-doc-tools``, and published to the Configuration Reference
|
|
and Command-Line Reference. For more information about these automated
|
|
tools, see the :ref:`doc-tools` chapter.
|
|
|
|
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, feel free to
|
|
add a note that you are happy to have editorial assistance on the patch.
|
|
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 know which book you want to modify, get in contact with the
|
|
appropriate speciality team, listed at :doc:`../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.
|
|
* If you want to create a new Installation Tutorial for your big tent
|
|
project, see :doc:`../project-install-guide`.
|
|
* Remember, you can always contact the documentation team through our mailing
|
|
list, or on IRC.
|