openstack/openstack-manuals
Code Issues Proposed changes
896c259dc5
openstack-manuals/doc/contributor-guide/source/quickstart/developers.rst
Lana Brindley b3ba9020bd Contributor Guide miscellaneous process updates 
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
2016-07-25 22:14:21 +00:00

2.1 KiB
Raw Blame History

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 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. 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 ../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 ../project-install-guide.
  • Remember, you can always contact the documentation team through our mailing list, or on IRC.