mirror of
https://github.com/ansible/ansible-documentation.git
synced 2026-03-27 13:28:51 +07:00
f73b6e11c7
(cherry picked from commit a6e9ce42e4)
Co-authored-by: Vishal Perla <vishal260805@gmail.com>
50 lines
2.3 KiB
Markdown
50 lines
2.3 KiB
Markdown
# How to Contribute
|
|
|
|
The ansible-documention project is [GPL-3.0 licensed](COPYING) and accepts contributions through
|
|
GitHub pull requests.
|
|
|
|
## Certificate of Origin
|
|
|
|
By contributing to ansible-documentation, you agree to the Developer Certificate of
|
|
Origin (DCO). This document was created by the Linux Kernel community and is a
|
|
simple statement that you, as a contributor, have the legal right to make the
|
|
contribution. See the [DCO](DCO) file for details.
|
|
|
|
## Backport labels
|
|
|
|
This repository has `stable-<MAJOR>.<MINOR>` branches to correspond to each
|
|
ansible-core major release.
|
|
ansible-documentation committers can add `backport-<MAJOR>.<MINOR>` labels to
|
|
pull requests so the [Patchback bot] will automatically create backport pull
|
|
requests after the original PR is merged.
|
|
Small fixes or cleanups should at least be backported to the latest
|
|
stable branch.
|
|
If a PR should stay on the `devel` and not be backported—for example, if the
|
|
documentation update addresses an ansible-core change that only occurred on the
|
|
ansible-core development branch—maintainers should instead add the
|
|
`no_backport` label.
|
|
|
|
[Patchback bot]: https://github.com/apps/patchback
|
|
|
|
## Merging pull requests
|
|
|
|
This repository has two ways to apply pull requests:
|
|
`Squash and merge` and `Create a merge commit`.
|
|
`Squash and merge` squashes all of the commits from the PR's base branch into a
|
|
single commit and then applies that commit on top of the target branch in the
|
|
upstream ansible-documentation repository.
|
|
`Create a merge commit` uses `git merge` which preserves the entire commit
|
|
history from the base branch.
|
|
This may not be desired if, for example, there are a lot of fixup commits with
|
|
nondescriptive commit messages.
|
|
For other more complex changes—especially those that involve the docs build
|
|
scripts or other tooling code—it may be desirable to preserve the full commit
|
|
history to keep logical changes separated and avoid clobbering useful metadata
|
|
so the Git history remains useful in the future. The maintainer who merges the
|
|
PR can select the merge mode through the dropdown menu next to the green merge
|
|
button.
|
|
Generally, maintainers should apply PRs using `Squash and merge`.
|
|
`Create a merge commit` should be used if the PR author added the
|
|
`merge_commit` label or the maintainer otherwise assesses that merge mode makes
|
|
sense for the change in question.
|