This section contains information you should know before contributing new content.
There are also dedicated pages about submitting case studies and blog articles.
Figure - Contributing new content preparation
The figure above depicts the information you should know prior to submitting new content. The information details follow.
/content/en/docs/
. Some of the reference documentation is automatically generated from scripts in the update-imported-docs/
directory./content/
. Each language has its own folder with a two-letter code determined by the ISO 639-1 standard . For example, English documentation source is stored in /content/en/docs/
.All Kubernetes contributors must read the Contributor guide and sign the Contributor License Agreement (CLA) .
Pull requests from contributors who haven't signed the CLA fail the automated tests. The name and email you provide must match those found in your git config
, and your git name and email must match those used for the CNCF CLA.
When opening a pull request, you need to know in advance which branch to base your work on.
Scenario | Branch |
---|---|
Existing or new English language content for the current release | main |
Content for a feature change release | The branch which corresponds to the major and minor version the feature change is in, using the pattern dev-<version> . For example, if a feature changes in the v1.34 release, then add documentation changes to the dev-1.34 branch. |
Content in other languages (localizations) | Use the localization's convention. See the Localization branching strategy for more information. |
If you're still not sure which branch to choose, ask in #sig-docs
on Slack.
Limit pull requests to one language per PR. If you need to make an identical change to the same code sample in multiple languages, open a separate PR for each language.
The doc contributors tools directory in the kubernetes/website
repository contains tools to help your contribution journey go more smoothly.