We welcome contributions from our community as well as from Adobe employees from 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:
If you are contributing minor updates out of the goodness of your heart, visit the article and click the Edit link in the article that goes to the GitHub source for the article. Then, just 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 you want to create a new article or submit major changes, please use the Issues tab in the Git repository to submit an issue to start a conversation with the documentation team. Once you've agreed to a plan, you'll need to work with an employee to help bring that new content in through a combination of work in the public and private repositories.
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
.
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.
The _jekyll
directory contains templated topics and required assets.
The templates that use the Liquid templating language reside in the _jekyll/templated
directory as HTML files.
The _jekyll/_data
directory contains files with the data that is used to render the templates.
To render all templates:
-
Navigate to the
_jekyll
directory.cd _jekyll
-
Run the rendering script.
_scripts/render
NOTE: You must run the script from the
_jekyll
directory. NOTE: You must have Ruby installed to run this script.
The script runs rendering and writes rendered templates to the help/_includes/templated
directory.
See the Jekyll documentation for more details on [Data Files](https://jekyllrb.com/docs/datafiles, Liquid filters, and other features.