We know that Adobe Experience Manager users are working in highly competitive environments, striving to create digital experiences that will set them apart from their competitors. Therefore it is vital that when Adobe delivers advanced new tools in AEM, that these tools are complemented with accurate and clear documentation to allow the customer to immediately leverage their AEM investment and maximize ROI.
The goal of the AEM documentation is to put documentation into the hands of AEM users as soon as possible. Therefore we prioritize accurate, usable documentation and strive to continually update and improve it.
In the interest of continually improving AEM documentation, the entire community of AEM users are welcome to contribute to the documentation. Be it through pull requests or issues, improvements to the documentation can be corrections, clarifications, expansions, and additional examples.
While we welcome contributions to our documentation, any contribution to the AEM documentation, either in the form of a pull request or an issue, must conform to our contribution and documentation standards.
Contributions that do not meet these standards may be rejected.
AEM documentation covers standard use cases. Use cases beyond the scope of standard installation and usage of the product are not part of AEM documentation.
AEM documentation covers standard use cases. For this reason, bugs, effects caused by bugs, and workarounds for bugs are not generally not documented.
Exceptions to this rule apply to the release notes where known issues can be listed with possible solutions that have been approved by AEM Product Management.
Any ideas you may have to improve AEM documentation are welcome as contributions. However comments, issues, and pull requests are intended for contributions only. They are not intended to be used to answer your questions about how to use AEM or solve technical problems.
Any questions about the usage of AEM or technical errors you may have should be reported through the normal support process via the Experience Manager Support Portal or discussed in the Experience Manager community.
AEM documentation contributions are not a replacement for Adobe support and any such contributions seeking answers to support-related questions will be rejected.
If you create an issue to suggest improvements to the documentation, you must include include links to the pages affected. If you create an issue by using the Edit this page link on a documentation page, the issue will be created with a link to the page automatically.
This does not apply to pull requests since pull requests include the affected pages by definition.
We ask that any contributions to our documentation follow certain style guidelines.
Following these guidelines makes the review of your contribution easier and therefore integration into our documentation is faster. However noncompliance or incomplete compliance to these guidelines does not mean that the contribution will be rejected.
- AEM documentation is authored and maintained in US English.
- Keep sentences as simple as possible.
- Keep the language clear and concise.
Remember, readers of AEM documentation are worldwide and can not be expected to be native or fluent English speakers. Avoid colloquialisms and keep the language as clear and simple as possible.
The Microsoft Manual of Style is a freely available documentation style guide that focuses on software documentation and AEM documentation follows this guide wherever possible.
| Item | Style |
|---|---|
| UI Element or option | bold |
| Filename, path, user-input, parameter-values | monospaced |
| Code, command line | Code Block |
Screen shots are to be used judiciously and only when a textual description is insufficient.
Markers or other annotations in screenshots (like red frames, arrows or text) should not be used. This way the screenshots are easier to re-use or replicate in localized versions of the documentation.
Try to avoid any direct references to a specific version throughout the documentation content whenever possible. This makes the documentation more flexible and extensible for future versions.
The product should always be referred to by its full name Adobe Experience Manager for the first time in an article and can thereafter be referred to as AEM.
Day, Day Software, CQ, and CRX should not be used except where unavoidable such as in class names or referring to the history of AEM.