whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Restructure to reduce duplication

Browse Source 
Signed-off-by: Celeste Horgan <celeste@cncf.io>
This commit is contained in:
Celeste Horgan
2020-04-02 16:03:51 -07:00
parent fafe93382e
commit f0cded013f
20 changed files with 1274 additions and 1488 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/contribute/new-content/_index.md
+4
View File
@@ -0,0 +1,4 @@
---
title: Contributing new content
weight: 20
---
content/en/docs/contribute/new-content/blogs-case-studies.md
+60
View File
@@ -0,0 +1,60 @@
---
title: Submitting blog posts and case studies
linktitle: Blogs and case studies
slug: blogs-case-studies
content_template: templates/concept
weight: 30
---
{{% capture overview %}}
Anyone can write a blog post and submit it for review.
Case studies require extensive review before they're approved.
{{% /capture %}}
{{% capture body %}}
## Write a blog post
Blog posts should not be
vendor pitches. They must contain content that applies broadly to
the Kubernetes community. The SIG Docs [blog subproject](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject) manages the review process for blog posts. For more information, see [Submit a post](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post).
To submit a blog post, you can either:
- Use the
[Kubernetes blog submission form](https://docs.google.com/forms/d/e/1FAIpQLSdMpMoSIrhte5omZbTE7nB84qcGBy8XnnXhDFoW0h7p2zwXrw/viewform)
- [Open a pull request](/docs/contribute/new-content/open-a-pr/#fork-the-repo) with a new blog post. Create new blog posts in the [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts) directory.
If you open a pull request, ensure that your blog post follows the correct naming conventions and frontmatter information:
- The markdown file name must follow the format `YYY-MM-DD-Your-Title-Here.md`. For example, `2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md`.
- The front matter must include the following:
```yaml
---
layout: blog
title: "Your Title Here"
date: YYYY-MM-DD
slug: text-for-URL-link-here-no-spaces
---
```
## Submit a case study
Case studies highlight how organizations are using Kubernetes to solve
real-world problems. The Kubernetes marketing team and members of the {{< glossary_tooltip text="CNCF" term_id="cncf" >}} collaborate with you on all case studies.
Have a look at the source for the
[existing case studies](https://github.com/kubernetes/website/tree/master/content/en/case-studies).
Use the [Kubernetes case study submission form](https://www.cncf.io/people/end-user-community/)
to submit your proposal.
{{% /capture %}}
{{% capture whatsnext %}}
{{% /capture %}}
content/en/docs/contribute/new-content/new-features.md
+134
View File
@@ -0,0 +1,134 @@
---
title: Documenting a feature for a release
linktitle: Documenting for a release
content_template: templates/concept
main_menu: true
weight: 20
card:
name: contribute
weight: 45
title: Documenting a feature for a release
---
{{% capture overview %}}
Each major Kubernetes release introduces new features that require documentation. New releases also bring updates to existing features and documentation (such as upgrading a feature from alpha to beta).
Generally, the SIG responsible for a feature submits draft documentation of the
feature as a pull request to the appropriate release branch of the
`kubernetes/website` repository, and someone on the SIG Docs team provides
editorial feedback or edits the draft directly. This section covers the branching
conventions and process used during a release by both groups.
{{% /capture %}}
{{% capture body %}}
## For documentation contributors
In general, documentation contributors don't write content from scratch for a release.
Instead, they work with the SIG creating a new feature to refine the draft documentation and make it release ready.
After you've chosen a feature to document or assist, ask about it in the `#sig-docs`
Slack channel, in a weekly SIG Docs meeting, or directly on the PR filed by the
feature SIG. If you're given the go-ahead, you can edit into the PR using one of
the techniques described in
[Commit into another person's PR](/docs/contribute/review/for-approvers/#commit-into-another-persons-pr).
### Find out about upcoming features
To find out about upcoming features, attend the weekly SIG Release meeting (see
the [community](https://kubernetes.io/community/) page for upcoming meetings)
and monitor the release-specific documentation
in the [kubernetes/sig-release](https://github.com/kubernetes/sig-release/)
repository. Each release has a sub-directory in the [/sig-release/tree/master/releases/](https://github.com/kubernetes/sig-release/tree/master/releases)
directory. The sub-directory contains a release schedule, a draft of the release
notes, and a document listing each person on the release team.
The release schedule contains links to all other documents, meetings,
meeting minutes, and milestones relating to the release. It also contains
information about the goals and timeline of the release, and any special
processes in place for this release. Near the bottom of the document, several
release-related terms are defined.
This document also contains a link to the **Feature tracking sheet**, which is
the official way to find out about all new features scheduled to go into the
release.
The release team document lists who is responsible for each release role. If
it's not clear who to talk to about a specific feature or question you have,
either attend the release meeting to ask your question, or contact the release
lead so that they can redirect you.
The release notes draft is a good place to find out about
specific features, changes, deprecations, and more about the release. The
content is not finalized until late in the release cycle, so use caution.
### Feature tracking sheet
The feature tracking sheet [for a given Kubernetes release](https://github.com/kubernetes/sig-release/tree/master/releases)
lists each feature that is planned for a release.
Each line item includes the name of the feature, a link to the feature's main
GitHub issue, its stability level (Alpha, Beta, or Stable), the SIG and
individual responsible for implementing it, whether it
needs docs, a draft release note for the feature, and whether it has been
merged. Keep the following in mind:
- Beta and Stable features are generally a higher documentation priority than
Alpha features.
- It's hard to test (and therefore to document) a feature that hasn't been merged,
or is at least considered feature-complete in its PR.
- Determining whether a feature needs documentation is a manual process and
just because a feature is not marked as needing docs doesn't mean it doesn't
need them.
## For developers or other SIG members
This section is information for members of other Kubernetes SIGs documenting new features
for a release.
If you are a member of a SIG developing a new feature for Kubernetes, you need
to work with SIG Docs to be sure your feature is documented in time for the
release. Check the
[feature tracking spreadsheet](https://github.com/kubernetes/sig-release/tree/master/releases)
or check in the `#sig-release` Kubernetes Slack channel to verify scheduling details and
deadlines.
### Open a placeholder PR
1. Open a pull request against the
`release-X.Y` branch in the `kubernetes/website` repository, with a small
commit that you will amend later.
2. Use the Prow command `/milestone X.Y` to
assign the PR to the relevant milestone. This alerts the docs person managing
this release that the feature docs are coming.
If your feature does not need
any documentation changes, make sure the sig-release team knows this, by
mentioning it in the `#sig-release` Slack channel. If the feature does need
documentation but the PR is not created, the feature may be removed from the
milestone.
### PR ready for review
When ready, populate your placeholder PR with feature documentation.
Do your best to describe your feature and how to use it. If you need help structuring your documentation, ask in the `#sig-docs` slack channel.
When you complete your content, the documentation person assigned to your feature reviews it. Use their suggestions to get the content to a release ready state.
If your feature needs documentation and the first draft
content is not received, the feature may be removed from the milestone.
### All PRs reviewed and ready to merge
If your PR has not yet been merged into the `release-X.Y` branch by the release deadline, work with the
docs person managing the release to get it in by the deadline. If your feature needs
documentation and the docs are not ready, the feature may be removed from the
milestone.
If your feature is an Alpha feature and is behind a feature gate, make sure you
add it to [Alpha/Beta Feature gates](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features) table
as part of your pull request. If your feature is moving out of Alpha, make sure to
remove it from that table.
{{% /capture %}}
content/en/docs/contribute/new-content/open-a-pr.md
+484
View File
@@ -0,0 +1,484 @@
---
title: Opening a pull request
slug: new-content
content_template: templates/concept
weight: 10
card:
name: contribute
weight: 40
---
{{% capture overview %}}
{{< note >}}
**Code developers**: If you are documenting a new feature for an
upcoming Kubernetes release, see
[Document a new feature](/docs/contribute/new-content/new-features/).
{{< /note >}}
To contribute new content pages or improve existing content pages, open a pull request (PR). Make sure you follow all the requirements in the [Before you begin](#before-you-begin) section.
If your change is small, or you're unfamiliar with git, read [Changes using GitHub](#changes-using-github) to learn how to edit a page.
If your changes are large, read [Work from a local fork](#fork-the-repo) to learn how to make changes locally on your computer.
{{% /capture %}}
{{% capture body %}}
## Changes using GitHub
If you're less experienced with git workflows, here's an easier method of
opening a pull request.
1. On the page where you see the issue, select the pencil icon at the top right.
You can also scroll to the bottom of the page and select **Edit this page**.
2. Make your changes in the GitHub markdown editor.
3. Below the editor, fill in the **Propose file change**
form. In the first field, give your commit message a title. In
the second field, provide a description.
{{< note >}}
Do not use any [GitHub Keywords](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) in your commit message. You can add those to the pull request
description later.
{{< /note >}}
4. Select **Propose file change**.
5. Select **Create pull request**.
6. The **Open a pull request** screen appears. Fill in the form:
- The **Subject** field of the pull request defaults to the commit summary.
You can change it if needed.
- The **Body** contains your extended commit message, if you have one,
and some template text. Add the
details the template text asks for, then delete the extra template text.
- Leave the **Allow edits from maintainers** checkbox selected.
{{< note >}}
PR descriptions are a great way to help reviewers understand your change. For more information, see [Opening a PR](#open-a-pr).
{{</ note >}}
7. Select **Create pull request**.
### Addressing feedback in GitHub
Before merging a pull request, Kubernetes community members review and
approve it. The `k8s-ci-robot` suggests reviewers based on the nearest
owner mentioned in the pages. If you have someone specific in mind,
leave a comment with their GitHub username in it.
If a reviewer asks you to make changes:
1. Go to the **Files changed** tab.
2. Select the pencil (edit) icon on any files changed by the
pull request.
3. Make the changes requested.
4. Commit the changes.
If you are waiting on a reviewer, reach out once every 7 days. You can also post a message in the `#sig-docs` Slack channel.
When your review is complete, a reviewer merges your PR and your changes go live a few minutes later.
## Work from a local fork {#fork-the-repo}
If you're more experienced with git, or if your changes are larger than a few lines,
work from a local fork.
Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) installed on your computer. You can also use a git UI application.
### Fork the kubernetes/website repository
1. Navigate to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository.
2. Select **Fork**.
### Create a local clone and set the upstream
3. In a terminal window, clone your fork:
```bash
git clone git@github.com/<github_username>/website
```
4. Navigate to the new `website` directory. Set the `kubernetes/website` repository as the `upstream` remote:
```bash
cd website
git remote add upstream https://github.com/kubernetes/website.git
```
5. Confirm your `origin` and `upstream` repositories:
```bash
git remote -v
```
Output is similar to:
```bash
origin git@github.com:<github_username>/website.git (fetch)
origin git@github.com:<github_username>/website.git (push)
upstream https://github.com/kubernetes/website (fetch)
upstream https://github.com/kubernetes/website (push)
```
6. Fetch commits from your fork's `origin/master` and `kubernetes/website`'s `upstream/master`:
```bash
git fetch origin
git fetch upstream
```
This makes sure your local repository is up to date before you start making changes.
{{< note >}}
This workflow is different than the [Kubernetes Community GitHub Workflow](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md). You do not need to merge your local copy of `master` with `upstream/master` before pushing updates to your fork.
{{< /note >}}
### Create a branch
1. Decide which branch base to your work on:
- For improvements to existing content, use `upstream/master`.
- For new content about existing features, use `upstream/master`.
- For localized content, use the localization's conventions. For more information, see [localizing Kubernetes documentation](/docs/contribute/localization/).
- For new features in an upcoming Kubernetes release, use the feature branch. For more information, see [documenting for a release](/docs/contribute/new-content/new-features/).
- For long-running efforts that multiple SIG Docs contributors collaborate on,
like content reorganization, use a specific feature branch created for that
effort.
If you need help choosing a branch, ask in the `#sig-docs` Slack channel.
2. Create a new branch based on the branch identified in step 1. This example assumes the base branch is `upstream/master`:
```bash
git checkout -b <my_new_branch> upstream/master
```
3. Make your changes using a text editor.
At any time, use the `git status` command to see what files you've changed.
### Commit your changes
When you are ready to submit a pull request, commit your changes.
1. In your local repository, check which files you need to commit:
```bash
git status
```
Output is similar to:
```bash
On branch <my_new_branch>
Your branch is up to date with 'origin/<my_new_branch>'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: content/en/docs/contribute/new-content/contributing-content.md
no changes added to commit (use "git add" and/or "git commit -a")
```
2. Add the files listed under **Changes not staged for commit** to the commit:
```bash
git add <your_file_name>
```
Repeat this for each file.
3. After adding all the files, create a commit:
```bash
git commit -m "Your commit message"
```
{{< note >}}
Do not use any [GitHub Keywords](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) in your commit message. You can add those to the pull request
description later.
{{< /note >}}
4. Push your local branch and its new commit to your remote fork:
```bash
git push origin <my_new_branch>
```
### Preview your changes locally {#preview-locally}
It's a good idea to preview your changes locally before pushing them or opening a pull request. A preview lets you catch build errors or markdown formatting problems.
You can either build the website's docker image or run Hugo locally. Building the docker image is slower but displays [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/), which can be useful for debugging.
{{< tabs name="tab_with_hugo" >}}
{{% tab name="Hugo in a container" %}}
1. Build the image locally:
```bash
make docker-image
```
2. After building the `kubernetes-hugo` image locally, build and serve the site:
```bash
make docker-serve
```
3. In a web browser, navigate to `https://localhost:1313`. Hugo watches the
changes and rebuilds the site as needed.
4. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`,
or close the terminal window.
{{% /tab %}}
{{% tab name="Hugo on the command line" %}}
Alternately, install and use the `hugo` command on your computer:
5. Install the [Hugo](https://gohugo.io/getting-started/installing/) version specified in [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml).
6. In a terminal, go to your Kubernetes website repository and start the Hugo server:
```bash
cd <path_to_your_repo>/website
hugo server
```
7. In your browser’s address bar, enter `https://localhost:1313`.
8. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`,
or close the terminal window.
{{% /tab %}}
{{< /tabs >}}
### Open a pull request from your fork to kubernetes/website {#open-a-pr}
1. In a web browser, go to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository.
2. Select **New Pull Request**.
3. Select **compare across forks**.
4. From the **head repository** drop-down menu, select your fork.
5. From the **compare** drop-down menu, select your branch.
6. Select **Create Pull Request**.
7. Add a description for your pull request:
- **Title** (50 characters or less): Summarize the intent of the change.
- **Description**: Describe the change in more detail.
- If there is a related GitHub issue, include `Fixes #12345` or `Closes #12345` in the description. GitHub's automation closes the mentioned issue after merging the PR if used. If there are other related PRs, link those as well.
- If you want advice on something specific, include any questions you'd like reviewers to think about in your description.
8. Select the **Create pull request** button.
Congratulations! Your pull request is available in [Pull requests](https://github.com/kubernetes/website/pulls).
After opening a PR, GitHub runs automated tests and tries to deploy a preview using [Netlify](https://www.netlify.com/).
- If the Netlify build fails, select **Details** for more information.
- If the Netlify build succeeds, select **Details** opens a staged version of the Kubernetes website with your changes applied. This is how reviewers check your changes.
GitHub also automatically assigns labels to a PR, to help reviewers. You can add them too, if needed. For more information, see [Adding and removing issue labels](/docs/contribute/review/for-approvers/#adding-and-removing-issue-labels).
### Addressing feedback locally
1. After making your changes, amend your previous commit:
```bash
git commit -a --amend
```
- `-a`: commits all changes
- `--amend`: amends the previous commit, rather than creating a new one
2. Update your commit message if needed.
3. Use `git push origin <my_new_branch>` to push your changes and re-run the Netlify tests.
{{< note >}}
If you use `git commit -m` instead of amending, you must [squash your commits](#squashing-commits) before merging.
{{< /note >}}
#### Changes from reviewers
Sometimes reviewers commit to your pull request. Before making any other changes, fetch those commits.
1. Fetch commits from your remote fork and rebase your working branch:
```bash
git fetch origin
git rebase origin/<your-branch-name>
```
2. After rebasing, force-push new changes to your fork:
```bash
git push --force-with-lease origin <your-branch-name>
```
#### Merge conflicts and rebasing
{{< note >}}
For more information, see [Git Branching - Basic Branching and Merging](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts), [Advanced Merging](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging), or ask in the `#sig-docs` Slack channel for help.
{{< /note >}}
If another contributor commits changes to the same file in another PR, it can create a merge conflict. You must resolve all merge conflicts in your PR.
1. Update your fork and rebase your local branch:
```bash
git fetch origin
git rebase origin/<your-branch-name>
```
Then force-push the changes to your fork:
```bash
git push --force-with-lease origin <your-branch-name>
```
2. Fetch changes from `kubernetes/website`'s `upstream/master` and rebase your branch:
```bash
git fetch upstream
git rebase upstream/master
```
3. Inspect the results of the rebase:
```bash
git status
```
This results in a number of files marked as conflicted.
4. Open each conflicted file and look for the conflict markers: `>>>`, `<<<`, and `===`. Resolve the conflict and delete the conflict marker.
{{< note >}}
For more information, see [How conflicts are presented](https://git-scm.com/docs/git-merge#_how_conflicts_are_presented).
{{< /note >}}
5. Add the files to the changeset:
```bash
git add <filename>
```
6. Continue the rebase:
```bash
git rebase --continue
```
7. Repeat steps 2 to 5 as needed.
After applying all commits, the `git status` command shows that the rebase is complete.
8. Force-push the branch to your fork:
```bash
git push --force-with-lease origin <your-branch-name>
```
The pull request no longer shows any conflicts.
### Squashing commits
{{< note >}}
For more information, see [Git Tools - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History), or ask in the `#sig-docs` Slack channel for help.
{{< /note >}}
If your PR has multiple commits, you must squash them into a single commit before merging your PR. You can check the number of commits on your PR's **Commits** tab or by running the `git log` command locally.
{{< note >}}
This topic assumes `vim` as the command line text editor.
{{< /note >}}
1. Start an interactive rebase:
```bash
git rebase -i HEAD~<number_of_commits_in_branch>
```
Squashing commits is a form of rebasing. The `-i` switch tells git you want to rebase interactively. `HEAD~<number_of_commits_in_branch` indicates how many commits to look at for the rebase.
Output is similar to:
```bash
pick d875112ca Original commit
pick 4fa167b80 Address feedback 1
pick 7d54e15ee Address feedback 2
# Rebase 3d18sf680..7d54e15ee onto 3d183f680 (3 commands)
...
# These lines can be re-ordered; they are executed from top to bottom.
```
The first section of the output lists the commits in the rebase. The second section lists the options for each commit. Changing the word `pick` changes the status of the commit once the rebase is complete.
For the purposes of rebasing, focus on `squash` and `pick`.
{{< note >}}
For more information, see [Interactive Mode](https://git-scm.com/docs/git-rebase#_interactive_mode).
{{< /note >}}
2. Start editing the file.
Change the original text:
```bash
pick d875112ca Original commit
pick 4fa167b80 Address feedback 1
pick 7d54e15ee Address feedback 2
```
To:
```bash
pick d875112ca Original commit
squash 4fa167b80 Address feedback 1
squash 7d54e15ee Address feedback 2
```
This squashes commits `4fa167b80 Address feedback 1` and `7d54e15ee Address feedback 2` into `d875112ca Original commit`, leaving only `d875112ca Original commit` as a part of the timeline.
3. Save and exit your file.
4. Push your squashed commit:
```bash
git push --force-with-lease origin <branch_name>
```
## Contribute to other repos
The [Kubernetes project](https://github.com/kubernetes) contains 50+ repositories. Many of these repositories contain documentation: user-facing help text, error messages, API references or code comments.
If you see text you'd like to improve, use GitHub to search all repositories in the Kubernetes organization.
This can help you figure out where to submit your issue or PR.
Each repository has its own processes and procedures. Before you file an
issue or submit a PR, read that repository's `README.md`, `CONTRIBUTING.md`, and
`code-of-conduct.md`, if they exist.
Most repositories use issue and PR templates. Have a look through some open
issues and PRs to get a feel for that team's processes. Make sure to fill out
the templates with as much detail as possible when you file issues or PRs.
{{% /capture %}}
{{% capture whatsnext %}}
- Read [Reviewing](/docs/contribute/reviewing/revewing-prs) to learn more about the review process.
{{% /capture %}}
content/en/docs/contribute/new-content/overview.md
+73
View File
@@ -0,0 +1,73 @@
---
title: Contributing new content overview
linktitle: Overview
content_template: templates/concept
main_menu: true
weight: 5
---
{{% capture overview %}}
This section contains information you should know before contributing new content.
{{% /capture %}}
{{% capture body %}}
## Contributing basics
- Write Kubernetes documentation in Markdown and build the Kubernetes site using [Hugo](https://gohugo.io/).
- The source is in [GitHub](https://github.com/kubernetes/website). You can find Kubernetes documentation at `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory.
- [Page templates](/docs/contribute/style/page-templates/) control the presentation of documentation content in Hugo.
- In addition to the standard Hugo shortcodes, we use a number of [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our documentation to control the presentation of content.
- Documentation source is available in multiple languages in `/content/`. Each language has its own folder with a two-letter code determined by the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For example, English documentation source is stored in `/content/en/docs/`.
- For more information about contributing to documentation in multiple languages or starting a new translation, see [localization](/docs/contribute/localization).
## Before you begin {#before-you-begin}
### Sign the CNCF CLA {#sign-the-cla}
All Kubernetes contributors **must** read the [Contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) and [sign the Contributor License Agreement (CLA)](https://github.com/kubernetes/community/blob/master/CLA.md).
Pull requests from contributors who haven't signed the CLA fail the automated tests.
### Configure commit signoffs
All commits to Kubernetes repositories must be _signed off_ using the Git `--signoff` or `-s` flag.
The signoff acknowledges that you have the rights to submit contributions under the same
license and [Developer Certificate of Origin](https://developercertificate.org/).
If you're using a Git UI app, you can use the app's commit template functionality if it
exists, or add the following to your commit message body:
```
Signed-off-by: Your Name <youremail@domain.com>
```
In both cases, 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.
### Choose which Git branch to use
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 | `master`
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-release-<version>`. For example, if a feature changes in the `{{< latest-version >}}` release, then add documentation changes to the ``dev-{{< release-branch >}}`` branch.
Content in other languages (localizations) | Use the localization's convention. See the [Localization branching strategy](/docs/contribute/localization/#branching-strategy) for more information.
If you're still not sure which branch to choose, ask in `#sig-docs` on Slack.
{{< note >}}
If you already submitted your pull request and you know that the base branch
was wrong, you (and only you, the submitter) can change it.
{{< /note >}}
### Languages per PR
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.
{{% /capture %}}