Update docs for primary branch rename to "main"

Author: Tim Bannister

content/en/docs/concepts/cluster-administration/manage-deployment.md

@@ -50,7 +50,7 @@ It is a recommended practice to put resources related to the same microservice o
 A URL can also be specified as a configuration source, which is handy for deploying directly from configuration files checked into GitHub:
 
 ```shell
-kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/application/nginx/nginx-deployment.yaml
+kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/application/nginx/nginx-deployment.yaml
 ```
 
 ```shell

content/en/docs/contribute/generate-ref-docs/quickstart.md

@@ -18,8 +18,8 @@ the build setup and generates the reference documentation for a release.
 
 ## Getting the docs repository
 
-Make sure your `website` fork is up-to-date with the `kubernetes/website` master and clone
-your `website` fork.
+Make sure your `website` fork is up-to-date with the `kubernetes/website` remote on
+GitHub (`main` branch), and clone your `website` fork.
 
 ```shell
 mkdir github.com
@@ -171,7 +171,7 @@ For example:
 The `release.yml` configuration file contains instructions to fix relative links.
 To fix relative links within your imported files, set the`gen-absolute-links`
 property to `true`. You can find an example of this in
-[`release.yml`](https://github.com/kubernetes/website/blob/master/update-imported-docs/release.yml).
+[`release.yml`](https://github.com/kubernetes/website/blob/main/update-imported-docs/release.yml).
 
 ## Adding and committing changes in kubernetes/website
 

content/en/docs/contribute/localization.md

@@ -98,7 +98,7 @@ Once you've opened a localization PR, you can become members of the Kubernetes G
 
 ### Add your localization team in GitHub
 
-Next, add your Kubernetes localization team to [`sig-docs/teams.yaml`](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml). For an example of adding a localization team, see the PR to add the [Spanish localization team](https://github.com/kubernetes/org/pull/685).
+Next, add your Kubernetes localization team to [`sig-docs/teams.yaml`](https://github.com/kubernetes/org/blob/main/config/kubernetes/sig-docs/teams.yaml). For an example of adding a localization team, see the PR to add the [Spanish localization team](https://github.com/kubernetes/org/pull/685).
 
 Members of `@kubernetes/sig-docs-**-owners` can approve PRs that change content within (and only within) your localization directory: `/content/**/`.
 
@@ -117,7 +117,7 @@ For an example of adding a label, see the PR for adding the [Italian language la
 
 ### Modify the site configuration
 
-The Kubernetes website uses Hugo as its web framework. The website's Hugo configuration resides in the  [`config.toml`](https://github.com/kubernetes/website/tree/master/config.toml) file. To support a new localization, you'll need to modify `config.toml`.
+The Kubernetes website uses Hugo as its web framework. The website's Hugo configuration resides in the  [`config.toml`](https://github.com/kubernetes/website/tree/main/config.toml) file. To support a new localization, you'll need to modify `config.toml`.
 
 Add a configuration block for the new language to `config.toml`, under the existing `[languages]` block. The German block, for example, looks like:
 
@@ -136,7 +136,7 @@ For more information about Hugo's multilingual support, see "[Multilingual Mode]
 
 ### Add a new localization directory
 
-Add a language-specific subdirectory to the [`content`](https://github.com/kubernetes/website/tree/master/content) folder in the repository. For example, the two-letter code for German is `de`:
+Add a language-specific subdirectory to the [`content`](https://github.com/kubernetes/website/tree/main/content) folder in the repository. For example, the two-letter code for German is `de`:
 
 ```shell
 mkdir content/de
@@ -219,7 +219,7 @@ For an example of adding a new localization, see the PR to enable [docs in Frenc
 
 ### Add a localized README file
 
-To guide other localization contributors, add a new [`README-**.md`](https://help.github.com/articles/about-readmes/) to the top level of k/website, where `**` is the two-letter language code. For example, a German README file would be `README-de.md`.
+To guide other localization contributors, add a new [`README-**.md`](https://help.github.com/articles/about-readmes/) to the top level of [k/website](https://github.com/kubernetes/website/), where `**` is the two-letter language code. For example, a German README file would be `README-de.md`.
 
 Provide guidance to localization contributors in the localized `README-**.md` file. Include the same information contained in `README.md` as well as:
 
@@ -276,15 +276,15 @@ To find source files for your target version:
 2. Select a branch for your target version from the following table:
     Target version | Branch
     -----|-----
-    Latest version | [`master`](https://github.com/kubernetes/website/tree/master)
+    Latest version | [`main`](https://github.com/kubernetes/website/tree/main)
     Previous version | [`release-{{< skew prevMinorVersion >}}`](https://github.com/kubernetes/website/tree/release-{{< skew prevMinorVersion >}})
     Next version | [`dev-{{< skew nextMinorVersion >}}`](https://github.com/kubernetes/website/tree/dev-{{< skew nextMinorVersion >}})
 
-The `master` branch holds content for the current release `{{< latest-version >}}`. The release team will create a `{{< release-branch >}}` branch before the next release: v{{< skew nextMinorVersion >}}.
+The `main` branch holds content for the current release `{{< latest-version >}}`. The release team will create a `{{< release-branch >}}` branch before the next release: v{{< skew nextMinorVersion >}}.
 
 ### Site strings in i18n
 
-Localizations must include the contents of [`data/i18n/en/en.toml`](https://github.com/kubernetes/website/blob/master/data/i18n/en/en.toml) in a new language-specific file. Using German as an example: `data/i18n/de/de.toml`.
+Localizations must include the contents of [`data/i18n/en/en.toml`](https://github.com/kubernetes/website/blob/main/data/i18n/en/en.toml) in a new language-specific file. Using German as an example: `data/i18n/de/de.toml`.
 
 Add a new localization directory and file to `data/i18n/`. For example, with German (`de`):
 
@@ -339,14 +339,14 @@ Repeat steps 1-4 as needed until the localization is complete. For example, subs
 Teams must merge localized content into the same branch from which the content was sourced.
 
 For example:
-- a localization branch sourced from `master` must be merged into `master`.
-- a localization branch sourced from `release-1.19` must be merged into `release-1.19`.
+- a localization branch sourced from `main` must be merged into `main`.
+- a localization branch sourced from `release-{{ skew "prevMinorVersion" }}` must be merged into `release-{{ skew "prevMinorVersion" }}`.
 
 {{< note >}}
-If your localization branch was created from `master` branch but it is not merged into `master` before new release branch `{{< release-branch >}}` created, merge it into both `master` and new release branch `{{< release-branch >}}`. To merge your localization branch into new release branch `{{< release-branch >}}`, you need to switch upstream branch of your localization branch to `{{< release-branch >}}`.
+If your localization branch was created from `main` branch but it is not merged into `main` before new release branch `{{< release-branch >}}` created, merge it into both `main` and new release branch `{{< release-branch >}}`. To merge your localization branch into new release branch `{{< release-branch >}}`, you need to switch upstream branch of your localization branch to `{{< release-branch >}}`.
 {{< /note >}}
 
-At the beginning of every team milestone, it's helpful to open an issue comparing upstream changes between the previous localization branch and the current localization branch. There are two scripts for comparing upstream changes. [`upstream_changes.py`](https://github.com/kubernetes/website/tree/master/scripts#upstream_changespy) is useful for checking the changes made to a specific file. And [`diff_l10n_branches.py`](https://github.com/kubernetes/website/tree/master/scripts#diff_l10n_branchespy) is useful for creating a list of outdated files for a specific localization branch.
+At the beginning of every team milestone, it's helpful to open an issue comparing upstream changes between the previous localization branch and the current localization branch. There are two scripts for comparing upstream changes. [`upstream_changes.py`](https://github.com/kubernetes/website/tree/main/scripts#upstream_changespy) is useful for checking the changes made to a specific file. And [`diff_l10n_branches.py`](https://github.com/kubernetes/website/tree/main/scripts#diff_l10n_branchespy) is useful for creating a list of outdated files for a specific localization branch.
 
 While only approvers can open a new localization branch and merge pull requests, anyone can open a pull request for a new localization branch. No special permissions are required.
 

content/en/docs/contribute/new-content/blogs-case-studies.md

@@ -40,7 +40,7 @@ Anyone can write a blog post and submit it for review.
     - Many CNCF projects have their own blog. These are often a better choice for posts. There are times of major feature or milestone for a CNCF project that users would be interested in reading on the Kubernetes blog.
 - Blog posts should be original content
   - The official blog is not for repurposing existing content from a third party as new content.
-  - The [license](https://github.com/kubernetes/website/blob/master/LICENSE) for the blog allows commercial use of the content for commercial purposes, but not the other way around.
+  - The [license](https://github.com/kubernetes/website/blob/main/LICENSE) for the blog allows commercial use of the content for commercial purposes, but not the other way around.
 - Blog posts should aim to be future proof
   - Given the development velocity of the project, we want evergreen content that won't require updates to stay accurate for the reader. 
   - It can be a better choice to add a tutorial or update official documentation than to write a high level overview as a blog post.
@@ -56,7 +56,7 @@ The SIG Docs [blog subproject](https://github.com/kubernetes/community/tree/mast
 
 To submit a blog post follow these directions:
 
-- [Open a pull request](/docs/contribute/new-content/open-a-pr/#fork-the-repo) with a new blog post. New blog posts go under the [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts) directory.
+- [Open a pull request](/docs/contribute/new-content/open-a-pr/#fork-the-repo) with a new blog post. New blog posts go under the [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/main/content/en/blog/_posts) directory.
 
 - Ensure that your blog post follows the correct naming conventions and the following frontmatter (metadata) information:
 
@@ -90,6 +90,6 @@ 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).
+[existing case studies](https://github.com/kubernetes/website/tree/main/content/en/case-studies).
 
 Refer to the [case study guidelines](https://github.com/cncf/foundation/blob/master/case-study-guidelines.md) and submit your request as outlined in the guidelines.

content/en/docs/contribute/new-content/open-a-pr.md

@@ -127,7 +127,7 @@ Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installi
     upstream	https://github.com/kubernetes/website.git (push)
     ```
 
-6. Fetch commits from your fork's `origin/master` and `kubernetes/website`'s `upstream/master`:
+6. Fetch commits from your fork's `origin/main` and `kubernetes/website`'s `upstream/main`:
 
     ```bash
     git fetch origin
@@ -137,15 +137,15 @@ Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installi
     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.
+    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 `main` with `upstream/main` 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 improvements to existing content, use `upstream/main`.
+  - For new content about existing features, use `upstream/main`.
   - 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,
@@ -154,10 +154,10 @@ Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installi
 
     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`:
+2. Create a new branch based on the branch identified in step 1. This example assumes the base branch is `upstream/main`:
 
     ```bash
-    git checkout -b <my_new_branch> upstream/master
+    git checkout -b <my_new_branch> upstream/main
     ```
 
 3.  Make your changes using a text editor.
@@ -262,7 +262,7 @@ The commands below use Docker as default container engine. Set the `CONTAINER_EN
 
 Alternately, install and use the `hugo` command on your computer:
 
-1.  Install the [Hugo](https://gohugo.io/getting-started/installing/) version specified in [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml).
+1.  Install the [Hugo](https://gohugo.io/getting-started/installing/) version specified in [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/main/netlify.toml).
 
 2.  If you have not updated your website repository, the `website/themes/docsy` directory is empty.
     The site cannot build without a local copy of the theme. To update the website theme, run:
@@ -370,11 +370,11 @@ If another contributor commits changes to the same file in another PR, it can cr
     git push --force-with-lease origin <your-branch-name>
     ```
 
-2. Fetch changes from `kubernetes/website`'s `upstream/master` and rebase your branch:
+2. Fetch changes from `kubernetes/website`'s `upstream/main` and rebase your branch:
 
     ```bash
     git fetch upstream
-    git rebase upstream/master
+    git rebase upstream/main
     ```
 
 3. Inspect the results of the rebase:

content/en/docs/contribute/new-content/overview.md

@@ -42,7 +42,7 @@ When opening a pull request, you need to know in advance which branch to base yo
 
 Scenario | Branch
 :---------|:------------
-Existing or new English language content for the current release | `master`
+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 `v{{< skew nextMinorVersion >}}` release, then add documentation changes to the ``dev-{{< skew nextMinorVersion >}}`` branch.
 Content in other languages (localizations) | Use the localization's convention. See the [Localization branching strategy](/docs/contribute/localization/#branching-strategy) for more information.
 
@@ -60,6 +60,6 @@ Limit pull requests to one language per PR. If you need to make an identical cha
 
 ## Tools for contributors
 
-The [doc contributors tools](https://github.com/kubernetes/website/tree/master/content/en/docs/doc-contributor-tools) directory in the `kubernetes/website` repository contains tools to help your contribution journey go more smoothly.
+The [doc contributors tools](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools) directory in the `kubernetes/website` repository contains tools to help your contribution journey go more smoothly.
 
 

content/en/docs/contribute/participate/_index.md

@@ -73,8 +73,8 @@ two [prow plugins](https://github.com/kubernetes/test-infra/tree/master/prow/plu
 - approve
 
 These two plugins use the
-[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) and
-[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES)
+[OWNERS](https://github.com/kubernetes/website/blob/main/OWNERS) and
+[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES)
 files in the top level of the `kubernetes/website` GitHub repository to control
 how prow works within the repository.
 

content/en/docs/contribute/participate/pr-wranglers.md

@@ -44,8 +44,8 @@ These queries exclude localization PRs. All queries are against the main branch
   Lists PRs that need an LGTM from a member. If the PR needs technical review, loop in one of the reviewers suggested by the bot. If the content needs work, add suggestions and feedback in-line.
 - [Has LGTM, needs docs approval](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+label%3Algtm+):
   Lists PRs that need an `/approve` comment to merge.
-- [Quick Wins](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22): Lists PRs against the main branch with no clear blockers. (change "XS" in the size label as you work through the PRs [XS, S, M, L, XL, XXL]).
-- [Not against the main branch](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3Alanguage%2Fen+-base%3Amaster): If the PR is against a `dev-` branch, it's for an upcoming release. Assign the [docs release manager](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles) using: `/assign @<manager's_github-username>`. If the PR is against an old branch, help the author figure out whether it's targeted against the best branch.
+- [Quick Wins](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amain+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22): Lists PRs against the main branch with no clear blockers. (change "XS" in the size label as you work through the PRs [XS, S, M, L, XL, XXL]).
+- [Not against the primary branch](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3Alanguage%2Fen+-base%3Amain): If the PR is against a `dev-` branch, it's for an upcoming release. Assign the [docs release manager](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles) using: `/assign @<manager's_github-username>`. If the PR is against an old branch, help the author figure out whether it's targeted against the best branch.
 
 ### Helpful Prow commands for wranglers