====== Writing Release Notes and Documentation for New Features ======
===== Release Notes=====

Every new feature (or otherwise significant change to Evergreen) should have a short description of what it does differently than before, and how to get it working. In particular, it should list any new settings or permissions included with the feature, and any existing settings or permissions that are required to use the feature. Also, if the feature influences the upgrade process (e.g. by adding required steps, increasing the ingest time, etc.), you should include this information in an “Upgrade Notes” section. Otherwise, Release Notes should be kept short and should usually not include screenshots or step-by-step instructions. 

Files can be added to the source directory “RELEASE_NOTES_NEXT” in the appropriate subdirectory. Upgrade notes can be included in an “Upgrade Notes” section of your release notes or added as a separate file to an “upgrade” subdirectory within your appropriate subdirectory.

Bug fix release notes that don't require a longer explanation can make use of the Release-Notes: tag in git commit message.  This automatically generates a release notes entry with a link to the bug report.  See [[https://bugs.launchpad.net/evergreen/+bug/2051874|original bug report]] for details.

===== Normal Documentation =====

This should contain everything an Evergreen user or administrator needs to know about the new feature (or otherwise significant change to Evergreen). Screenshots and step-by-step instructions are generally very helpful. Files can be added to the source directory “DOCS_NEXT”. If you know where this information would fit best in the existing Evergreen documentation, please mention that on the DIG email list or add your files to the appropriate subdirectory under the “docs/” source directory.