Adobe Experience Manager users are working in highly competitive environments, striving to create digital experiences that set them apart from their competitors. Therefore, when Adobe delivers advanced tools in AEM, these tools are complemented with accurate and clear documentation. It lets customers immediately use their AEM investment and maximize their return on investment.
The goal of the AEM documentation is to put documentation into the hands of AEM users as soon as possible. Therefore, Adobe prioritizes accurate, usable documentation, and strives to update and improve it continually.
In the interest of continually improving AEM documentation, the entire community of AEM users is welcome to contribute to the documentation. Be it through pull requests or issues, improvements to the documentation can be corrections, clarifications, expansions, and other examples.
While Adobe welcomes contributions to its documentation, any contribution to the AEM documentation in a pull request or an issue, should conform to Adobe's 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 documented.
Exceptions to this rule apply to the release notes where known issues can be listed with possible solutions that Product Management have approved.
Any ideas you have to improve AEM documentation are welcome as contributions. However, any comments, issues, and pull requests are intended as contributions only. They are not to answer your questions about how to use AEM, implement your AEM project, or solve technical problems.
You can report any questions about AEM usage or technical errors. Use the normal support process by way of the Experience Cloud Enterprise Support portal or discussed in the Experience Manager community.
AEM documentation contributions are not a replacement for Adobe Customer Care and any such contributions seeking answers to support-related questions are rejected.
If you create an issue to suggest improvements to the documentation, you must include links to the pages affected. If you create an issue by using the Edit this page link on a documentation page, the issue is created with a link to the page automatically.
This process does not apply to pull requests because pull requests, by their nature, reference the affected pages.
Adobe asks that any contributions to its documentation follow certain style guidelines.
Following these guidelines makes the review of your contribution easier and therefore, integration into Adobe's documentation is faster.
- 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 cannot 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 |
Screenshots 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 reuse 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 recommendation makes the documentation more flexible and extensible for future versions.
In an article, always refer to the product by its full name Adobe Experience Manager the first time it is used. Thereafter, it can 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.