We welcome content contributions from our community and Adobe employees outside the documentation teams.
This project has adopted the Adobe Open Source Code of Conduct or the .NET Foundation Code of Conduct. For more information, see the Contributing article.
See the Adobe Docs Contributor Guide.
How you contribute depends on who you are and the sort of changes you'd like to contribute:
To submit a request, click the Log an issue link in an article, which opens an issue in GitHub. Specify a title and a description, and then click Submit new issue.
To request minor updates, click the Edit this page link in an article, which opens the source article in GitHub. Use the GitHub UI to make your updates. See the general Adobe Docs contributor guide for more information.
Minor corrections or clarifications you submit for documentation and code examples in this repo are covered by the Adobe terms of use.
If you're part of the Adobe community and want to create an article or submit major changes, click the Issues tab in the GitHub repository to submit an issue. This submission starts a conversation with the documentation team. You will need to work with the writer (or other Adobe employee) to publish new content.
If you are a technical writer, program manager, or developer from the product team for an Adobe Experience Cloud solution, and it's your job to contribute to or author technical articles, you should use the private repository at https://git.corp.adobe.com/AdobeDocs
. See the Internal Collaboration Guide for more information.
As stated above, members of the Adobe community can submit an issue that will be assigned to the appropriate writer. If you are an Adobe employee, you can submit an issue or contact the Experience Platform documentation team directly. To find the lead writer for a specific Platform area, see the Adobe Experience Platform Documentation wiki.
Community contributors can use the GitHub UI for basic editing or fork the repo to make major contributions.
See the Adobe Docs Contributor Guide for details.
All the articles in this repository use GitHub flavored markdown. If you are not familiar with markdown, see:
In the public repository, automated labels are assigned to pull requests to help us manage the pull request workflow and to help let you know what's going on with your pull request:
- Change sent to author: The author has been notified of the pending pull request.
- ready-to-merge: Ready for review by our pull request review team.