Normalize case: Github -> GitHub (#13828)

content/en/blog/_posts/2015-05-00-Kubernetes-Release-0170.md

@@ -140,7 +140,7 @@ Release Notes:
 * Update Exec and Portforward client to use pod subresource [#7715][127] (csrwng)
 * Added NFS to PV structs [#7564][128] (markturansky)
 * Fix environment variable error in Vagrant docs [#7904][129] (posita)
-* Adds a simple release-note builder that scrapes the Github API for recent PRs [#7616][130](brendandburns)
+* Adds a simple release-note builder that scrapes the GitHub API for recent PRs [#7616][130](brendandburns)
 * Scheduler ignores nodes that are in a bad state [#7668][131] (bprashanth)
 * Set GOMAXPROCS for etcd [#7863][132] (fgrzadkowski)
 * Auto-generated conversion methods calling one another [#7556][133] (wojtek-t)
@@ -444,7 +444,7 @@ Simple theme. Powered by [Blogger][385].
 [127]: https://github.com/GoogleCloudPlatform/kubernetes/pull/7715 "Update Exec and Portforward client to use pod subresource"
 [128]: https://github.com/GoogleCloudPlatform/kubernetes/pull/7564 "Added NFS to PV structs"
 [129]: https://github.com/GoogleCloudPlatform/kubernetes/pull/7904 "Fix environment variable error in Vagrant docs"
-[130]: https://github.com/GoogleCloudPlatform/kubernetes/pull/7616 "Adds a simple release-note builder that scrapes the Github API for recent PRs"
+[130]: https://github.com/GoogleCloudPlatform/kubernetes/pull/7616 "Adds a simple release-note builder that scrapes the GitHub API for recent PRs"
 [131]: https://github.com/GoogleCloudPlatform/kubernetes/pull/7668 "Scheduler ignores nodes that are in a bad state"
 [132]: https://github.com/GoogleCloudPlatform/kubernetes/pull/7863 "Set GOMAXPROCS for etcd"
 [133]: https://github.com/GoogleCloudPlatform/kubernetes/pull/7556 "Auto-generated conversion methods calling one another"

content/en/blog/_posts/2015-07-00-How-Did-Quake-Demo-From-Dockercon-Work.md

@@ -169,7 +169,7 @@ The LPC demo was done with a simple container that did not require network conne
 In May 2015, the criu branch of libcontainer was merged into master.  Using the newly-introduced lightweight [runC](https://blog.docker.com/2015/06/runc/) container runtime, container migration was demo’ed at DockerCon15.  In this
 [![demo](https://img.youtube.com/vi/7vZ9dRKRMyc/0.jpg)](https://www.youtube.com/watch?v=?mL9AFkJJAq0) (minute 23:00), a container running Quake was checkpointed and restored on a different machine, effectively implementing container migration.
 
-At the time of this writing, there are two repos on Github that have native C/R support in Docker:
+At the time of this writing, there are two repos on GitHub that have native C/R support in Docker:
 - [Docker 1.5](https://github.com/SaiedKazemi/docker/tree/cr) (old libcontainer, relatively stable)
 - [Docker 1.7](https://github.com/boucher/docker/tree/cr-combined) (newer, less stable)  
 

content/en/blog/_posts/2015-12-00-Creating-Raspberry-Pi-Cluster-Running.md

@@ -12,7 +12,7 @@ Now you got your Raspberry Pi Cluster all setup, it is time to run some software
 First step is to make sure every Pi has Hypriot running, if not yet please check the [getting started guide](http://blog.hypriot.com/getting-started-with-docker-on-your-arm-device/) of them. Also hook up the cluster switch to a network so that Internet is available and every Pi get an IP-address assigned via DHCP. Because we will be running multiple Pi’s it is practical to give each Pi a unique hostname. I renamed my Pi’s to rpi-master, rpi-node-1, rpi-node-2, etc for my convenience. Note that on Hypriot the hostname is set by editing the /boot/occidentalis.txt file, not the /etc/hostname. You could also set the hostname using the Hypriot flash tool.
 
 
-The most important thing about running software on a Pi is the availability of an ARM distribution. Thanks to [Brendan Burns](https://twitter.com/brendandburns), there are Kubernetes components for ARM available in the [Google Cloud Registry](https://cloud.google.com/container-registry/docs/). That’s great. The second hurdle is how to install Kubernetes. There are two ways; directly on the system or in a Docker container. Although the container support has an experimental status, I choose to go for that because it makes it easier to install Kubernetes for you. Kubernetes requires several processes (etcd, flannel, kubectl, etc) to run on a node, which should be started in a specific order. To ease that, systemd services are made available to start the necessary processes in the right way. Also the systemd services make sure that Kubernetes is spun up when a node is (re)booted. To make the installation real easy I created an simple install script for the master node and the worker nodes. All is available at [Github](https://github.com/awassink/k8s-on-rpi). So let’s get started now!
+The most important thing about running software on a Pi is the availability of an ARM distribution. Thanks to [Brendan Burns](https://twitter.com/brendandburns), there are Kubernetes components for ARM available in the [Google Cloud Registry](https://cloud.google.com/container-registry/docs/). That’s great. The second hurdle is how to install Kubernetes. There are two ways; directly on the system or in a Docker container. Although the container support has an experimental status, I choose to go for that because it makes it easier to install Kubernetes for you. Kubernetes requires several processes (etcd, flannel, kubectl, etc) to run on a node, which should be started in a specific order. To ease that, systemd services are made available to start the necessary processes in the right way. Also the systemd services make sure that Kubernetes is spun up when a node is (re)booted. To make the installation real easy I created an simple install script for the master node and the worker nodes. All is available at [GitHub](https://github.com/awassink/k8s-on-rpi). So let’s get started now!
 
 ### Installing the Kubernetes master node
 

content/en/blog/_posts/2016-02-00-Kubernetes-community-meeting-notes-20160211.md

@@ -22,7 +22,7 @@ Note taker: Rob Hirschfeld
   * *SIG Report:*
     * Release Automation and an introduction to David McMahon
     * Docs and k8s website redesign proposal and an introduction to John Mulhausen
-    * This will allow the system to build docs correctly from Github w/ minimal effort
+    * This will allow the system to build docs correctly from GitHub w/ minimal effort
     * Will be check-in triggered
     * Getting website style updates
     * Want to keep authoring really light
@@ -33,7 +33,7 @@ Note taker: Rob Hirschfeld
     * discussion about release criteria: we will hold release date for bugs
 * Testing flake surge is over (one time event and then maintain test stability)
 * 1.3 Planning (time +40 minutes)
-    * working to cleanup the Github milestones — they should be a source of truth.  you can use Github for bug reporting
+    * working to cleanup the GitHub milestones — they should be a source of truth.  you can use GitHub for bug reporting
     * push off discussion while 1.2 crunch is under
     * Framework
         * dates

content/en/blog/_posts/2016-07-00-Oh-The-Places-You-Will-Go.md

@@ -14,7 +14,7 @@ _--Justin_
 
 You started with an excellent foundation - good declarative functionality, built around a solid API with a well defined schema and the machinery so that we could evolve going forwards. And sure enough, over your first year you grew so fast: autoscaling, HTTP load-balancing support (Ingress), support for persistent workloads including clustered databases (PetSets). You’ve made friends with more clouds (welcome Azure & OpenStack to the family), and even started to span zones and clusters (Federation). And these are just some of the most visible changes - there’s so much happening inside that brain of yours!  
 
-I think it’s wonderful you’ve remained so open in all that you do - you seem to write down everything on Github - for better or worse. I think we’ve all learned a lot about that on the way, like the perils of having engineers make scaling statements that are then weighed against claims made without quite the same framework of precision and rigor. But I’m proud that you chose not to lower your standards, but rose to the challenge and just ran faster instead - it might not be the most realistic approach, but it is the only way to move mountains!  
+I think it’s wonderful you’ve remained so open in all that you do - you seem to write down everything on GitHub - for better or worse. I think we’ve all learned a lot about that on the way, like the perils of having engineers make scaling statements that are then weighed against claims made without quite the same framework of precision and rigor. But I’m proud that you chose not to lower your standards, but rose to the challenge and just ran faster instead - it might not be the most realistic approach, but it is the only way to move mountains!  
 
 And yet, somehow, you’ve managed to avoid a lot of the common dead-ends that other open source software has fallen into, particularly as those projects got bigger and the developers end up working on it more than they use it directly. How did you do that? There’s a probably-apocryphal story of an employee at IBM that makes a huge mistake, and is summoned to meet with the big boss, expecting to be fired, only to be told “We just spent several million dollars training you. Why would we want to fire you?”. Despite all the investment google is pouring into you (along with Redhat and others), I sometimes wonder if the mistakes we are avoiding could be worth even more. There is a very open development process, yet there’s also an “oracle” that will sometimes course-correct by telling us what happens two years down the road if we make a particular design decision. This is a parent you should probably listen to!  
 

content/en/blog/_posts/2017-11-00-Kubernetes-Easy-Way.md

@@ -52,7 +52,7 @@ We’re done with step 1. In my experience it usually takes less than 5 minutes
 
 
 ## Deploy an Application to Kubernetes
-First go to [Codefresh and create an account using Github, Bitbucket, or Gitlab](https://codefresh.io/kubernetes-deploy/). As mentioned previously, Codefresh is free for both open source and smaller private projects. We’ll use it to create the configuration Yaml necessary to deploy our application to Kubernetes. Then we'll deploy our application and automate the process to happen every time we commit code changes. Here are the steps:  
+First go to [Codefresh and create an account using GitHub, Bitbucket, or Gitlab](https://codefresh.io/kubernetes-deploy/). As mentioned previously, Codefresh is free for both open source and smaller private projects. We’ll use it to create the configuration Yaml necessary to deploy our application to Kubernetes. Then we'll deploy our application and automate the process to happen every time we commit code changes. Here are the steps:  
 
 1. 1.Create a Codefresh account
 2. 2.Connect to Google Cloud (or other cluster)

content/en/blog/_posts/2017-12-00-Introducing-Kubeflow-Composable.md

@@ -5,7 +5,7 @@ slug: introducing-kubeflow-composable
 url: /blog/2017/12/Introducing-Kubeflow-Composable
 ---
 
-**_Today’s post is by David Aronchick and Jeremy Lewi, a PM and Engineer on the Kubeflow project, a new open source Github repo dedicated to making using machine learning (ML) stacks on Kubernetes easy, fast and extensible._**  
+**_Today’s post is by David Aronchick and Jeremy Lewi, a PM and Engineer on the Kubeflow project, a new open source GitHub repo dedicated to making using machine learning (ML) stacks on Kubernetes easy, fast and extensible._**  
 
 
 
@@ -19,7 +19,7 @@ Worse, these deployments are so tied to the clusters they have been deployed to
 
 
 ## Introducing Kubeflow
-To address these concerns, we’re announcing the creation of the Kubeflow project, a new open source Github repo dedicated to making using ML stacks on Kubernetes easy, fast and extensible. This repository contains:  
+To address these concerns, we’re announcing the creation of the Kubeflow project, a new open source GitHub repo dedicated to making using ML stacks on Kubernetes easy, fast and extensible. This repository contains:  
 
 - JupyterHub to create & manage interactive Jupyter notebooks
 - A Tensorflow [Custom Resource](/docs/concepts/api-extension/custom-resources/) (CRD) that can be configured to use CPUs or GPUs, and adjusted to the size of a cluster with a single setting

content/en/blog/_posts/2018-05-04-Announcing-Kubeflow-0-1.md

@@ -86,14 +86,14 @@ It’d be impossible to have gotten where we are without enormous help from ever
 * [PyTorch operator](https://github.com/kubeflow/pytorch-operator) for running PyTorch jobs
 * [Seldon Core](https://github.com/kubeflow/kubeflow/tree/master/kubeflow/seldon) for running complex model deployments and non-TensorFlow serving
 
-It’s difficult to overstate how much the community has helped bring all these projects (and more) to fruition. Just a few of the contributing companies include: Alibaba Cloud, Ant Financial, Caicloud, Canonical, Cisco, Datawire, Dell, Github, Google, Heptio, Huawei, Intel, Microsoft, Momenta, One Convergence, Pachyderm, Project Jupyter, Red Hat, Seldon, Uber and Weaveworks.
+It’s difficult to overstate how much the community has helped bring all these projects (and more) to fruition. Just a few of the contributing companies include: Alibaba Cloud, Ant Financial, Caicloud, Canonical, Cisco, Datawire, Dell, GitHub, Google, Heptio, Huawei, Intel, Microsoft, Momenta, One Convergence, Pachyderm, Project Jupyter, Red Hat, Seldon, Uber and Weaveworks.
 
 # Learning More
 
 If you’d like to try out Kubeflow, we have a number of options for you:
 
 1. You can use sample walkthroughs hosted on [Katacoda](https://www.katacoda.com/kubeflow)
-2. You can follow a guided tutorial with existing models from the [examples repository](https://github.com/kubeflow/examples). These include the [Github Issue Summarization](https://github.com/kubeflow/examples/tree/master/github_issue_summarization), [MNIST](https://github.com/kubeflow/examples/tree/master/mnist) and [Reinforcement Learning with Agents](https://github.com/kubeflow/examples/tree/master/agents).
+2. You can follow a guided tutorial with existing models from the [examples repository](https://github.com/kubeflow/examples). These include the [GitHub Issue Summarization](https://github.com/kubeflow/examples/tree/master/github_issue_summarization), [MNIST](https://github.com/kubeflow/examples/tree/master/mnist) and [Reinforcement Learning with Agents](https://github.com/kubeflow/examples/tree/master/agents).
 3. You can start a cluster on your own and try your own model. Any Kubernetes conformant cluster will support Kubeflow including those from contributors [Caicloud](https://www.prnewswire.com/news-releases/caicloud-releases-its-kubernetes-based-cluster-as-a-service-product-claas-20-and-the-first-tensorflow-as-a-service-taas-11-while-closing-6m-series-a-funding-300418071.html), [Canonical](https://jujucharms.com/canonical-kubernetes/), [Google](https://cloud.google.com/kubernetes-engine/docs/how-to/creating-a-container-cluster), [Heptio](https://heptio.com/products/kubernetes-subscription/), [Mesosphere](https://github.com/mesosphere/dcos-kubernetes-quickstart), [Microsoft](https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough), [IBM](https://cloud.ibm.com/docs/containers?topic=containers-cs_cluster_tutorial#cs_cluster_tutorial), [Red Hat/Openshift ](https://docs.openshift.com/container-platform/3.3/install_config/install/quick_install.html#install-config-install-quick-install)and [Weaveworks](https://www.weave.works/product/cloud/).
 
 There were also a number of sessions at KubeCon + CloudNativeCon  EU 2018 covering Kubeflow. The links to the talks are here; the associated videos will be posted in the coming days. 

content/en/blog/_posts/2018-07-10-coredns-ga.md

@@ -167,10 +167,10 @@ You can find out more on the [CoreDNS Blog](https://coredns.io/blog).
 
 CoreDNS is an incubated [CNCF](https:://cncf.io) project.
 
-We're most active on Slack (and Github):
+We're most active on Slack (and GitHub):
 
 - Slack: #coredns on <https://slack.cncf.io>
-- Github: <https://github.com/coredns/coredns>
+- GitHub: <https://github.com/coredns/coredns>
 
 More resources can be found:
 

content/en/blog/_posts/2018-07-18-11-ways-not-to-get-hacked.md

@@ -76,7 +76,7 @@ Don't forget: keeping these logs inside the cluster is a security threat in
 
 **Centralising authentication and authorisation across an organisation (aka Single Sign On) helps onboarding, offboarding, and consistent permissions for users**.
 
-Integrating Kubernetes with third party auth providers (like Google or Github) uses the remote platform's identity guarantees (backed up by things like 2FA) and prevents administrators having to reconfigure the Kubernetes API server to add or remove users.
+Integrating Kubernetes with third party auth providers (like Google or GitHub) uses the remote platform's identity guarantees (backed up by things like 2FA) and prevents administrators having to reconfigure the Kubernetes API server to add or remove users.
 
 [Dex](https://github.com/coreos/dex) is an OpenID Connect Identity (OIDC) and OAuth 2.0 provider with pluggable connectors. Pusher takes this a stage further with [some custom tooling](https://thenewstack.io/kubernetes-single-sign-one-less-identity/), and there are some [other](https://github.com/negz/kuberos) [helpers](https://github.com/micahhausler/k8s-oidc-helper) available with slightly different use cases.
 

content/en/blog/_posts/2018-08-10-introducing-kubebuilder.md

@@ -47,5 +47,5 @@ Kubebuilder is a project under [SIG API Machinery][SIG-APIMachinery] and is bein
  
  - Kubebuilder [chat room on Slack][slack-channel]
  - SIG [mailing list][mailing-list]
- - [Github issues][open-an-issue]
+ - [GitHub issues][open-an-issue]
  - Send a pull request in the [kubebuilder repo][kubebuilder-repo]

content/en/blog/_posts/2018-10-04-non-code-contributors-guide.md

@@ -28,7 +28,7 @@ Some of the ways that you can contribute to the Kubernetes community without wri
 - Project, program, and [product management](https://github.com/kubernetes/community/blob/master/sig-pm/README.md)
 - And many more!
 
-The guide to get started with Kubernetes project contribution is [documented on Github](https://github.com/kubernetes/community/tree/master/contributors/guide), and as the Non-Code Contributors Guide is a part of that Kubernetes Contributors Guide, it can be found [here](https://github.com/kubernetes/community/blob/master/contributors/guide/non-code-contributions.md). As stated earlier, this list is not exhaustive and will continue to be a work in progress.   
+The guide to get started with Kubernetes project contribution is [documented on GitHub](https://github.com/kubernetes/community/tree/master/contributors/guide), and as the Non-Code Contributors Guide is a part of that Kubernetes Contributors Guide, it can be found [here](https://github.com/kubernetes/community/blob/master/contributors/guide/non-code-contributions.md). As stated earlier, this list is not exhaustive and will continue to be a work in progress.   
 
 To date, the typical Non-Code contributions fall into the following categories:
 

content/en/community/_index.html

@@ -53,7 +53,7 @@ cid: community
                 <p>Get the latest news and updates.</p>
             </div>
             <div>
-                <a href="https://github.com/kubernetes/kubernetes">Github Project</a>
+                <a href="https://github.com/kubernetes/kubernetes">GitHub Project</a>
                 <p>Check out the project and consider contributing.</p>
             </div>
             <div>

content/en/docs/contribute/_index.md

@@ -26,7 +26,7 @@ For information on the Kubernetes documentation style guide, see the [style guid
   for specific criteria for membership.
 - A SIG Docs _reviewer_ is a member of the Kubernetes organization who has
   expressed interest in reviewing documentation pull requests and who has been
-  added to the appropriate Github group and `OWNERS` files in the Github
+  added to the appropriate GitHub group and `OWNERS` files in the GitHub
   repository, by a SIG Docs Approver.
 - A SIG Docs _approver_ is a member in good standing who has shown a continued
   commitment to the project. An approver can merge pull requests

content/en/docs/contribute/advanced.md

@@ -38,7 +38,7 @@ for weekly rotations. The PR wrangler's duties include:
   [Intermediate contributing](/docs/contribute/intermediate/) for guidelines
   about how SIG Docs uses metadata.
 
-### Helpful Github queries for wranglers
+### Helpful GitHub queries for wranglers
 
 The following queries are helpful when wrangling. After working through these three queries, the remaining list of PRs to be
 reviewed is usually small. These queries specifically exclude localization PRs, and only include the `master` branch (except for the last one).

content/en/docs/contribute/intermediate.md

@@ -67,7 +67,7 @@ and the [code of conduct](/community/code-of-conduct/)
 
 ### Find a PR to review
 
-To see all open PRs, go to the **Pull Requests** tab in the Github repository.
+To see all open PRs, go to the **Pull Requests** tab in the GitHub repository.
 A PR is eligible for review when it meets all of the following criteria:
 
 - Has the `cncf-cla:yes` tag
@@ -166,7 +166,7 @@ has signed the CLA.
           - If the PR does not need additional technical review, add the
             text `/lgtm` as well.
           - If the PR *does* need additional technical review, add the text
-            `/assign` with the Github username of the person who needs to
+            `/assign` with the GitHub username of the person who needs to
             provide technical review. Look at the `reviewers` field in the
             front-matter at the top of a given Markdown file to see who can
             provide technical review.
@@ -212,7 +212,7 @@ true:
 
 #### If the file is already changed by the PR
 
-This method uses the Github UI. If you prefer, you can use the command line
+This method uses the GitHub UI. If you prefer, you can use the command line
 even if the file you want to change is part of the PR, if you are more
 comfortable working that way.
 
@@ -227,7 +227,7 @@ author's fork) and now shows up in the PR and your changes are reflected in
 the **Files changed** tab. Leave a comment letting the PR author know you
 changed the PR.
 
-If the author is using the command line rather than the Github UI to work on
+If the author is using the command line rather than the GitHub UI to work on
 this PR, they need to fetch their fork's changes and rebase their local branch
 on the branch in their fork, before doing additional work on the PR.
 
@@ -235,7 +235,7 @@ on the branch in their fork, before doing additional work on the PR.
 
 If changes need to be made to a file that is not yet included in the PR, you
 need to use the command line. You can always use this method, if you prefer it
-to the Github UI.
+to the GitHub UI.
 
 1.  Get the URL for the author's fork. You can find it near the bottom of the
     **Conversation** tab. Look for the text **Add more commits by pushing to**.
@@ -244,7 +244,7 @@ to the Github UI.
 
 2.  Add the fork as a remote. In your terminal, go to your clone of the
     repository. Decide on a name to give the remote (such as the author's
-    Github username), and add the remote using the following syntax:
+    GitHub username), and add the remote using the following syntax:
 
       ```bash
       git remote add <name> <url-of-fork>
@@ -273,10 +273,10 @@ to the Github UI.
       git push <remote-name> <branch-name>
       ```
 
-7.  Go back to the Github IU and refresh the PR. Your changes appear. Leave the
+7.  Go back to the GitHub IU and refresh the PR. Your changes appear. Leave the
     PR author a comment letting them know you changed the PR.
 
-If the author is using the command line rather than the Github UI to work on
+If the author is using the command line rather than the GitHub UI to work on
 this PR, they need to fetch their fork's changes and rebase their local branch
 on the branch in their fork, before doing additional work on the PR.
 
@@ -284,7 +284,7 @@ on the branch in their fork, before doing additional work on the PR.
 
 For changes that require multiple files or changes that involve creating new
 files or moving files around, working from a local Git clone makes more sense
-than relying on the Github UI. These instructions use the `git` command and
+than relying on the GitHub UI. These instructions use the `git` command and
 assume that you have it installed locally. You can adapt them to use a local
 graphical Git client instead.
 
@@ -301,7 +301,7 @@ on the Kubernetes documentation.
       ```
 
       The new directory `website` is created in your current directory, with
-      the contents of the Github repository.
+      the contents of the GitHub repository.
 
 2.  Change to the new `website` directory. Rename the default `origin` remote
     to `upstream`.
@@ -312,7 +312,7 @@ on the Kubernetes documentation.
       git remote rename origin upstream
       ```
 
-3.  If you have not done so, create a fork of the repository on Github. In your
+3.  If you have not done so, create a fork of the repository on GitHub. In your
     web browser, go to
     [https://github.com/kubernetes/website](https://github.com/kubernetes/website)
     and click the **Fork** button. After a few seconds, you are redirected to
@@ -389,10 +389,10 @@ most up-to-date version of that branch.
       ```
 
       {{< note >}}
-      Do not reference a Github issue or pull request by ID or URL in the
+      Do not reference a GitHub issue or pull request by ID or URL in the
       commit message. If you do, it will cause that issue or pull request to get
       a notification every time the commit shows up in a new Git branch. You can
-      link issues and pull requests together later, in the Github UI.
+      link issues and pull requests together later, in the GitHub UI.
       {{< /note >}}
 
 5.  Optionally, you can test your change by staging the site locally using the
@@ -413,13 +413,13 @@ most up-to-date version of that branch.
       The results are more repeatable if you include the branch name.
 
 7.  At this point, if you go to https://github.com/kubernetes/website in your
-    web browser, Github detects that you pushed a new branch to your fork and
+    web browser, GitHub detects that you pushed a new branch to your fork and
     offers to create a pull request. Fill in the pull request template.
 
       - The title should be no more than 50 characters and summarize the intent
         of the change.
       - The long-form description should contain more information about the fix,
-        including a line like `Fixes #12345` if the pull request fixes a Github
+        including a line like `Fixes #12345` if the pull request fixes a GitHub
         issue. This will cause the issue to be closed automatically when the
         pull request is merged.
       - You can add labels or other metadata and assign reviewers. See
@@ -458,7 +458,7 @@ most up-to-date version of that branch.
 11. If someone else's change is merged into the branch your work is based on,
     and you have made changes to the same parts of the same files, a conflict
     might occur. If the pull request shows that there are conflicts to resolve,
-    you can resolve them using the Github UI or you can resolve them locally.
+    you can resolve them using the GitHub UI or you can resolve them locally.
 
       First, do step 10 to be sure that your fork and your local branch are in
       the same state.
@@ -578,7 +578,7 @@ These guidelines are not set in stone and are subject to change.
   - Priority labels: define the relative severity of the issue. These do not
     conform to those outlined in the
     [Kubernetes contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority), and can be one of `P1`, `P2`, or `P3`, if set.
-- To add a label, you can use Github's **Labels** widget if you are a Sig Docs
+- To add a label, you can use GitHub's **Labels** widget if you are a Sig Docs
   approver. Anyone who is a member of the Kubernetes organization can add a
   label by leaving a comment like `/label <label-to-add>`. The label must
   already exist. If you try to add a label that does not exist, the command is
@@ -716,7 +716,7 @@ notes, and a document listing each person on the release team.
 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
+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:
@@ -790,7 +790,7 @@ individual repositories. Many of these repositories contain code or content that
 can be considered documentation, such as user-facing help text, error messages,
 user-facing text in API references, or even code comments.
 
-If you see text and you aren't sure where it comes from, you can use Github's
+If you see text and you aren't sure where it comes from, you can use GitHub's
 search tool at the level of the Kubernetes organization to search through all
 repositories for that text. This can help you figure out where to submit your
 issue or PR.

content/en/docs/contribute/participating.md

@@ -96,16 +96,16 @@ in the Kubernetes organization. Follow these steps:
       SIG Docs member.
       {{< /note >}}
 
-2.  Open a Github issue in the `kubernetes/org` repository to request membership.
+2.  Open a GitHub issue in the `kubernetes/org` repository to request membership.
     Fill out the template using the guidelines at
     [Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md).
 
-3.  Let your sponsors know about the Github issue, either by at-mentioning them
+3.  Let your sponsors know about the GitHub issue, either by at-mentioning them
-    in the Github issue (adding a comment with `@<Github-username>`) or by sending them the link directly,
+    in the GitHub issue (adding a comment with `@<GitHub-username>`) or by sending them the link directly,
     so that they can add a `+1` vote.
 
 4.  When your membership is approved, the github admin team member assigned to your request updates the
-    Github issue to show approval and then closes the Github issue.
+    GitHub issue to show approval and then closes the GitHub issue.
     Congratulations, you are now a member!
 
 If for some reason your membership request is not accepted right away, the
@@ -116,7 +116,7 @@ again.
 
 Reviewers are members of the
 [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews)
-Github group. See [Teams and groups within SIG Docs](#teams-and-groups-within-sig-docs).
+GitHub group. See [Teams and groups within SIG Docs](#teams-and-groups-within-sig-docs).
 
 Reviewers review documentation pull requests and provide feedback on proposed
 changes.
@@ -158,14 +158,14 @@ will assign and suggest you as a reviewer on new pull requests.
 
 If you are approved, request that a current SIG Docs approver add you to the
 [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews)
-Github group. Only members of the `kubernetes-website-admins` Github group can
+GitHub group. Only members of the `kubernetes-website-admins` GitHub group can
-add new members to a Github group.
+add new members to a GitHub group.
 
 ### Approvers
 
 Approvers are members of the
 [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
-Github group. See [Teams and groups within SIG Docs](#teams-and-groups-within-sig-docs).
+GitHub group. See [Teams and groups within SIG Docs](#teams-and-groups-within-sig-docs).
 
 Approvers have the ability to merge a PR, and thus, to publish content on the
 Kubernetes website. To approve a PR, an approver leaves an `/approve` comment on
@@ -198,12 +198,12 @@ will assign and suggest you as a reviewer on new pull requests.
 
 If you are approved, request that a current SIG Docs approver add you to the
 [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
-Github group. Only members of the `kubernetes-website-admins` Github group can
+GitHub group. Only members of the `kubernetes-website-admins` GitHub group can
-add new members to a Github group.
+add new members to a GitHub group.
 
 #### Becoming a website admin
 
-Members of the `kubernetes-website-admins` Github group can manage Github group
+Members of the `kubernetes-website-admins` GitHub group can manage GitHub group
 membership and have full administrative rights to the settings of the repository,
 including the ability to add, remove, and troubleshoot webhooks. Not all SIG
 Docs approvers need this level of access.
@@ -232,16 +232,16 @@ for the current list of chairpersons.
 ## SIG Docs teams and automation
 
 Automation in SIG Docs relies on two different mechanisms for automation:
-Github groups and OWNERS files.
+GitHub groups and OWNERS files.
 
-### Github groups
+### GitHub groups
 
-The SIG Docs group defines two teams on Github:
+The SIG Docs group defines two teams on GitHub:
 
  - [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers)
  - [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews)
 
-Each can be referenced with their `@name` in Github comments to communicate with
+Each can be referenced with their `@name` in GitHub comments to communicate with
 everyone in that group.
 
 These teams overlap, but do not exactly match, the groups used by the automation
@@ -251,7 +251,7 @@ the automation uses information from OWNERS files.
 ### OWNERS files and front-matter
 
 The Kubernetes project uses an automation tool called prow for automation
-related to Github issues and pull requests. The
+related to GitHub issues and pull requests. The
 [Kubernetes website repository](https://github.com/kubernetes/website) uses
 two [prow plugins](https://github.com/kubernetes/test-infra/blob/master/prow/plugins.yaml#L210):
 
@@ -261,7 +261,7 @@ two [prow plugins](https://github.com/kubernetes/test-infra/blob/master/prow/plu
 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)
-files in the top level of the `kubernetes/website` Github repository to control
+files in the top level of the `kubernetes/website` GitHub repository to control
 how prow works within the repository.
 
 An OWNERS file contains a list of people who are SIG Docs reviewers and
@@ -271,7 +271,7 @@ descendents. For more information about OWNERS files in general, see
 [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md).
 
 In addition, an individual Markdown file can list reviewers and approvers in its
-front-matter, either by listing individual Github usernames or Github groups.
+front-matter, either by listing individual GitHub usernames or GitHub groups.
 
 The combination of OWNERS files and front-matter in Markdown files determines
 the advice PR owners get from automated systems about who to ask for technical

content/en/docs/contribute/start.md

@@ -14,7 +14,7 @@ If you want to get started contributing to the Kubernetes documentation, this
 page and its linked topics can help you get started. You don't need to be a
 developer or a technical writer to make a big impact on the Kubernetes
 documentation and user experience! All you need for the topics on this page is
-a [Github account](https://github.com/join) and a web browser.
+a [GitHub account](https://github.com/join) and a web browser.
 
 If you're looking for information on how to start contributing to Kubernetes
 code repositories, refer to
@@ -27,12 +27,12 @@ code repositories, refer to
 
 ## The basics about our docs
 
-The Kubernetes documentation is written in Markdown and processed and deployed using Hugo. The source is in Github at [https://github.com/kubernetes/website](https://github.com/kubernetes/website). Most of the documentation source is stored in `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory.
+The Kubernetes documentation is written in Markdown and processed and deployed using Hugo. The source is in GitHub at [https://github.com/kubernetes/website](https://github.com/kubernetes/website). Most of the documentation source is stored in `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory.
 
 You can file issues, edit content, and review changes from others, all from the
-Github website. You can also use Github's embedded history and search tools.
+GitHub website. You can also use GitHub's embedded history and search tools.
 
-Not all tasks can be done in the Github UI, but these are discussed in the 
+Not all tasks can be done in the GitHub UI, but these are discussed in the 
 [intermediate](/docs/contribute/intermediate/) and
 [advanced](/docs/contribute/advanced/) docs contribution guides.
 
@@ -78,7 +78,7 @@ If you're interested in starting a new localization, see ["Localization"](/docs/
 
 ## File actionable issues
 
-Anyone with a Github account can file an issue (bug report) against the
+Anyone with a GitHub account can file an issue (bug report) against the
 Kubernetes documentation. If you see something wrong, even if you have no idea
 how to fix it, [file an issue](#how-to-file-an-issue). The exception to this
 rule is a tiny bug like a typo that you intend to fix yourself. In that case,
@@ -90,7 +90,7 @@ you can instead [fix it](#improve-existing-content) without filing a bug first.
 
     If you see a problem in an existing page in the [Kubernetes docs](/docs/),
     go to the bottom of the page and click the **Create an Issue** button. If
-    you are not currently logged in to Github, log in. A Github issue form
+    you are not currently logged in to GitHub, log in. A GitHub issue form
     appears with some pre-populated content.
 
     Using Markdown, fill in as many details as you can. In places where you see
@@ -125,7 +125,7 @@ in mind:
 - Be respectful and avoid venting. For instance, "The docs about X suck" is not
   helpful or actionable feedback. The
   [Code of Conduct](/community/code-of-conduct/) also applies to interactions on
-  Kubernetes Github repositories.
+  Kubernetes GitHub repositories.
 
 ## Participate in SIG Docs discussions
 
@@ -145,7 +145,7 @@ You can also check the SIG Docs weekly meeting on the [Kubernetes community meet
 ## Improve existing content
 
 To improve existing content, you file a _pull request (PR)_ after creating a
-_fork_. Those two terms are [specific to Github](https://help.github.com/categories/collaborating-with-issues-and-pull-requests/).
+_fork_. Those two terms are [specific to GitHub](https://help.github.com/categories/collaborating-with-issues-and-pull-requests/).
 For the purposes of this topic, you don't need to know everything about them,
 because you can do everything using your web browser. When you continue to the
 [intermediate docs contributor guide](/docs/contribute/intermediate/), you will
@@ -201,9 +201,9 @@ Follow these steps to submit a pull request to improve the Kubernetes
 documentation.
 
 1.  On the page where you see the issue, click the pencil icon at the top right.
-    A new Github page appears, with some help text.
+    A new GitHub page appears, with some help text.
 2.  If you have never created a fork of the Kubernetes documentation
-    repository, you are prompted to do so. Create the fork under your Github
+    repository, you are prompted to do so. Create the fork under your GitHub
     username, rather than another organization you may be a member of. The
     fork usually has a URL such as `https://github.com/<username>/website`,
     unless you already have a repository with a conflicting name.
@@ -211,14 +211,14 @@ documentation.
     The reason you are prompted to create a fork is that you do not have
     access to push a branch directly to the definitive Kubernetes repository.
 
-3.  The Github Markdown editor appears with the source Markdown file loaded.
+3.  The GitHub Markdown editor appears with the source Markdown file loaded.
     Make your changes. Below the editor, fill in the **Propose file change**
     form. The first field is the summary of your commit message and should be
     no more than 50 characters long. The second field is optional, but can
     include more detail if appropriate.
 
     {{< note >}}
-Do not include references to other Github issues or pull
+Do not include references to other GitHub issues or pull
 requests in your commit message. You can add those to the pull request
 description later.
 {{< /note >}}
@@ -238,7 +238,7 @@ description later.
     {{< note >}}
 If you don't want to create the pull request now, you can do it
 later, by browsing to the main URL of the Kubernetes website repository or
-your fork's repository. The Github website will prompt you to create the
+your fork's repository. The GitHub website will prompt you to create the
 pull request if it detects that you pushed a new branch to your fork.
 {{< /note >}}
     
@@ -268,8 +268,8 @@ pull request if it detects that you pushed a new branch to your fork.
     change is live on the Kubernetes website a few minutes later.
 
 This is only one way to submit a pull request. If you are already a Git and
-Github advanced user, you can use a local GUI or command-line Git client
+GitHub advanced user, you can use a local GUI or command-line Git client
-instead of using the Github UI. Some basics about using the command-line Git
+instead of using the GitHub UI. Some basics about using the command-line Git
 client are discussed in the [intermediate](/docs/contribute/intermediate/) docs
 contribution guide.
 
@@ -332,7 +332,7 @@ or follow the steps below.
     the blog post, but don't put the date in the file name. The blog reviewers
     will work with you on the final file name and the date the blog will be
     published.
-5.  When you save the file, Github will walk you through the pull request
+5.  When you save the file, GitHub will walk you through the pull request
     process.
 6.  A blog post reviewer will review your submission and work with you on
     feedback and final details. When the blog post is approved, the blog will be

content/en/docs/doc-contributor-tools/snippets/README.md

@@ -46,6 +46,6 @@ Placeholder text is included.
 ## Submitting new snippets
 
 1.  Develop the snippet locally and verify that it works as expected.
-2.  Copy the template's code into the `atom-snippets.cson` file on Github. Raise a
+2.  Copy the template's code into the `atom-snippets.cson` file on GitHub. Raise a
     pull request, and ask for review from another Atom user in `#sig-docs` on
     Kubernetes Slack.

content/en/docs/setup/independent/create-cluster-kubeadm.md

@@ -617,7 +617,7 @@ control of your Kubernetes cluster.
 
 ## Feedback {#feedback}
 
-* For bugs, visit [kubeadm Github issue tracker](https://github.com/kubernetes/kubeadm/issues)
+* For bugs, visit [kubeadm GitHub issue tracker](https://github.com/kubernetes/kubeadm/issues)
 * For support, visit kubeadm Slack Channel:
   [#kubeadm](https://kubernetes.slack.com/messages/kubeadm/)
 * General SIG Cluster Lifecycle Development Slack Channel:

content/en/docs/setup/windows/intro-windows-in-kubernetes.md

@@ -515,7 +515,7 @@ If these steps don't resolve your problem, you can get help running Windows cont
 
 ## Reporting Issues and Feature Requests
 
-If you have what looks like a bug, or you would like to make a feature request, please use the [Github issue tracking system](https://github.com/kubernetes/kubernetes/issues). You can open issues on [GitHub](https://github.com/kubernetes/kubernetes/issues/new/choose) and assign them to SIG-Windows. You should first search the list of issues in case it was reported previously and comment with your experience on the issue and add additional logs. SIG-Windows Slack is also a great avenue to get some initial support and troubleshooting ideas prior to creating a ticket.
+If you have what looks like a bug, or you would like to make a feature request, please use the [GitHub issue tracking system](https://github.com/kubernetes/kubernetes/issues). You can open issues on [GitHub](https://github.com/kubernetes/kubernetes/issues/new/choose) and assign them to SIG-Windows. You should first search the list of issues in case it was reported previously and comment with your experience on the issue and add additional logs. SIG-Windows Slack is also a great avenue to get some initial support and troubleshooting ideas prior to creating a ticket.
 
 If filing a bug, please include detailed information about how to reproduce the problem, such as:
 

content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md

@@ -34,7 +34,7 @@ in the Kubernetes source directory for a canonical example.
 
 Package your scheduler binary into a container image. For the purposes of this example,
 let's just use the default scheduler (kube-scheduler) as our second scheduler as well.
-Clone the [Kubernetes source code from Github](https://github.com/kubernetes/kubernetes)
+Clone the [Kubernetes source code from GitHub](https://github.com/kubernetes/kubernetes)
 and build the source.
 
 ```shell

content/en/docs/tasks/debug-application-cluster/troubleshooting.md

@@ -90,7 +90,7 @@ The Kubernetes Official Forum [discuss.kubernetes.io](https://discuss.kubernetes
 ### Bugs and Feature requests
 
 If you have what looks like a bug, or you would like to make a feature request,
-please use the [Github issue tracking system](https://github.com/kubernetes/kubernetes/issues).
+please use the [GitHub issue tracking system](https://github.com/kubernetes/kubernetes/issues).
 
 Before you file an issue, please search existing issues to see if your issue is
 already covered.

content/es/community/_index.html

@@ -46,7 +46,7 @@ cid: community
                 <p> Obtenga las últimas noticias y actualizaciones. </p>
             </div>
             <div>
-                <a href="https://github.com/kubernetes/kubernetes"> Proyecto en Github </a>
+                <a href="https://github.com/kubernetes/kubernetes"> Proyecto en GitHub </a>
                 <p> Echa un vistazo al proyecto y considera contribuir. </p>
             </div>
             <div>

content/fr/docs/contribute/_index.md

@@ -22,7 +22,7 @@ Pour plus d'informations sur le guide de style de la documentation Kubernetes, r
 - Un _membre_ de l'organisation Kubernetes qui a [signé le CLA](/docs/contribute/start#sign-the-cla) et contribué un peu de temps et d'efforts au projet.
   Voir [Adhésion à la communauté](https://github.com/kubernetes/community/blob/master/community-membership.md) pour des critères spécifiques d'adhésion.
 - Un SIG Docs _relecteur_ est un membre de l'organisation Kubernetes qui
-  a exprimé son intérêt pour l'examen des Pull Requests de la documentation et qui a été ajouté au groupe Github approprié et aux fichiers `OWNERS` dans le Github référentiel, par un approbateur SIG Docs.
+  a exprimé son intérêt pour l'examen des Pull Requests de la documentation et qui a été ajouté au groupe GitHub approprié et aux fichiers `OWNERS` dans le GitHub référentiel, par un approbateur SIG Docs.
 - Un SIG Docs _approbateur_ est un membre en règle qui a démontré un engagement continu envers le projet.
   Un approbateur peut fusionner des Pull Requests et publier du contenu au nom de l'organisation Kubernetes.
   Les approbateurs peuvent également représenter les documents SIG dans la communauté plus large de Kubernetes.

content/fr/docs/contribute/start.md

@@ -13,7 +13,7 @@ card:
 
 Si vous souhaitez commencer à contribuer à la documentation de Kubernetes, cette page et les rubriques associées peuvent vous aider à démarrer.
 Vous n'avez pas besoin d'être un développeur ou un rédacteur technique pour avoir un impact important sur la documentation et l'expérience utilisateur de Kubernetes !
-Tout ce dont vous avez besoin pour les sujets de cette page est un compte [Github](https://github.com/join) et un navigateur web.
+Tout ce dont vous avez besoin pour les sujets de cette page est un compte [GitHub](https://github.com/join) et un navigateur web.
 
 Si vous recherchez des informations sur la façon de commencer à contribuer aux référentiels de code Kubernetes, reportez-vous à la section sur [les directives de la communauté Kubernetes](https://github.com/kubernetes/community/blob/master/governance.md).
 
@@ -24,14 +24,14 @@ Si vous recherchez des informations sur la façon de commencer à contribuer aux
 ## Les bases de notre documentation
 
 La documentation de Kubernetes est écrite en Markdown puis traitée et déployée à l’aide de Hugo.
-Le code source est sur Github: [https://github.com/kubernetes/website](https://github.com/kubernetes/website).
+Le code source est sur GitHub: [https://github.com/kubernetes/website](https://github.com/kubernetes/website).
 La majeure partie de la documentation anglaise est stockée dans `/content/en/docs/`.
 Une partie de la documentation de référence est automatiquement générée à partir de scripts du répertoire `update-imported-docs/`.
 
-Vous pouvez trier les issues, modifier le contenu et passer en revue les modifications des autres, le tout à partir du site Web de Github.
+Vous pouvez trier les issues, modifier le contenu et passer en revue les modifications des autres, le tout à partir du site Web de GitHub.
-Vous pouvez également utiliser l'historique intégré et les outils de recherche de Github.
+Vous pouvez également utiliser l'historique intégré et les outils de recherche de GitHub.
 
-Toutes les tâches ne peuvent pas être effectuées dans l’interface utilisateur Github, mais elles sont décrites dans les guides de contribution [intermédiaire](/docs/contribute/intermediate/) et [avancé](/docs/contribute/advanced/).
+Toutes les tâches ne peuvent pas être effectuées dans l’interface utilisateur GitHub, mais elles sont décrites dans les guides de contribution [intermédiaire](/docs/contribute/intermediate/) et [avancé](/docs/contribute/advanced/).
 
 ### Participer à SIG Docs
 
@@ -72,7 +72,7 @@ Si vous souhaitez démarrer une nouvelle traduction, voir ["Traduction"](/docs/c
 
 ## Déposer les problèmes pouvant faire l'objet d'une action
 
-Toute personne possédant un compte Github peut soumettre un problème (rapport de bogue) à la documentation de Kubernetes.
+Toute personne possédant un compte GitHub peut soumettre un problème (rapport de bogue) à la documentation de Kubernetes.
 Si vous voyez quelque chose qui ne va pas, même si vous ne savez pas comment le réparer, [ouvrez un ticket](#how-to-file-an-issue).
 L'exception à cette règle est un petit bug, comme une faute de frappe, que vous souhaitez réparer vous-même.
 Dans ce cas, vous pouvez plutôt [le réparer](#improve-existing-content) sans déposer un bogue d'abord.
@@ -82,8 +82,8 @@ Dans ce cas, vous pouvez plutôt [le réparer](#improve-existing-content) sans d
 - **Sur une page existante**
 
     Si vous voyez un problème dans une page existante de [la documentation Kubernetes](/docs/), allez au bas de la page et cliquez sur le bouton **Create an Issue**.
-    Si vous n'êtes pas actuellement connecté à Github, connectez-vous.
+    Si vous n'êtes pas actuellement connecté à GitHub, connectez-vous.
-    Un formulaire de ticket Github apparaît avec du contenu pré-rempli.
+    Un formulaire de ticket GitHub apparaît avec du contenu pré-rempli.
 
     À l’aide de Markdown, renseignez autant de détails que possible.
     Aux endroits où vous voyez des crochets vides (`[ ]`), mettre un `x` entre les crochets qui représente le choix approprié.
@@ -108,7 +108,7 @@ Pour nous assurer que nous comprenons votre problème et pouvons y donner suite,
   Par exemple, `Introduced by #987654`.
 - Soyez respectueux et restez constructif.
   Par exemple, "La documentation sur X est nulle" n'est pas utile ou avec des commentaires exploitables.
-  Le [Code de conduite](/community/code-of-conduct/) s'applique également aux interactions sur les référentiels Kubernetes Github.
+  Le [Code de conduite](/community/code-of-conduct/) s'applique également aux interactions sur les référentiels Kubernetes GitHub.
 
 ## Participer aux discussions SIG Docs
 
@@ -129,7 +129,7 @@ Vous pouvez également consulter la réunion hebdomadaire de SIG Docs sur [Calen
 ## Améliorer le contenu existant
 
 Pour améliorer le contenu existant, vous déposez une _pull request (PR)_ après avoir créé un _fork_.
-Ces deux termes sont [spécifiques à Github](https://help.github.com/categories/collaborating-with-issues-and-pull-requests/).
+Ces deux termes sont [spécifiques à GitHub](https://help.github.com/categories/collaborating-with-issues-and-pull-requests/).
 Pour les besoins de cette rubrique, vous n'avez pas besoin de tout savoir à leur sujet, car vous pouvez tout faire à l'aide de votre navigateur Web.
 Quand vous passerez au [Guide des contributeurs docs intermédiaires](/docs/contribute/intermediate/), vous aurez besoin de plus de connaissances en terminologie Git.
 
@@ -172,19 +172,19 @@ Suivez ces étapes pour soumettre une demande d'extraction afin d'améliorer la
 2.  Cliquez sur le premier bouton bleu, qui a le texte **Edit <page name>**.
 
     Si vous n'avez jamais créé de fork du référentiel de documentation Kubernetes, vous êtes invité à le faire.
-    Créez le fork sous votre nom d'utilisateur Github, plutôt que celui d'une autre organisation dont vous pourriez être membre.
+    Créez le fork sous votre nom d'utilisateur GitHub, plutôt que celui d'une autre organisation dont vous pourriez être membre.
     Le fork a généralement une URL telle que `https://github.com/<nom d'utilisateur>/website`, à moins que vous n'ayez déjà un dépôt avec un nom en conflit (website).
 
     La raison pour laquelle vous êtes invité à créer un fork est que vous n'avez pas le droit de pousser une branche directement dans le référentiel définitif de Kubernetes.
 
-3.  L'éditeur Github Markdown apparaît avec le fichier source Markdown chargé.
+3.  L'éditeur GitHub Markdown apparaît avec le fichier source Markdown chargé.
     Faites vos changements.
     Sous l'éditeur, remplissez le formulaire **Propose file change**.
     Le premier champ est le résumé de votre message de validation et ne doit pas dépasser 50 caractères.
     Le deuxième champ est facultatif, mais peut inclure plus de détails si nécessaire.
 
     {{< note >}}
-    Ne pas inclure de références à d’autres Github issues ou pull requests dans votre message de commit.
+    Ne pas inclure de références à d’autres GitHub issues ou pull requests dans votre message de commit.
     Vous pouvez les ajouter ultérieurement à la description de la demande d'extraction.
     {{< /note >}}
 
@@ -197,7 +197,7 @@ Suivez ces étapes pour soumettre une demande d'extraction afin d'améliorer la
 
     {{< note >}}
     Si vous ne voulez pas créer la pull request maintenant, vous pouvez le faire plus tard, en accédant à l'URL principale du référentiel de site Web Kubernetes ou du référentiel de votre fork.
-    Le site Web Github vous invitera à créer la pull request s'il détecte que vous avez poussé une nouvelle branche vers votre fork.
+    Le site Web GitHub vous invitera à créer la pull request s'il détecte que vous avez poussé une nouvelle branche vers votre fork.
     {{< /note >}}
 
 5.  L'écran **Open a pull request** apparait.
@@ -222,7 +222,7 @@ Suivez ces étapes pour soumettre une demande d'extraction afin d'améliorer la
 7.  Si votre modification est acceptée, un relecteur merge votre pull request, et le changement est en direct sur le site Web de Kubernetes quelques minutes plus tard.
 
 Ce n’est qu’un moyen de soumettre une pull request.
-Si vous êtes déjà un utilisateur expérimenté de Git et Github, vous pouvez utiliser une interface graphique locale ou un client Git en ligne de commande au lieu d'utiliser l'interface utilisateur de Github.
+Si vous êtes déjà un utilisateur expérimenté de Git et GitHub, vous pouvez utiliser une interface graphique locale ou un client Git en ligne de commande au lieu d'utiliser l'interface utilisateur de GitHub.
 Quelques notions de base sur l’utilisation du client Git en ligne de commande sont abordées dans la section [intermédiaire](/docs/contribute/intermediate/) du guide des contributeurs.
 
 ## Relecture des pull requests de documentation
@@ -270,7 +270,7 @@ Pour soumettre un article de blog, vous pouvez soit le soumettre en utilisant le
     Collez votre contenu dans l'éditeur.
     Nommez le fichier pour qu'il corresponde au titre proposé de l'article de blog, mais ne mettez pas la date dans le nom du fichier.
     Les réviseurs de blog travailleront avec vous sur le nom de fichier final et la date de publication du blog.
-1.  Lorsque vous enregistrez le fichier, Github vous guidera à travers le processus d'une pull request.
+1.  Lorsque vous enregistrez le fichier, GitHub vous guidera à travers le processus d'une pull request.
 1.  Un critique de publication de blog examinera votre soumission et travaillera avec vous sur les commentaires et les détails finaux.
     Lorsque l'article du blog est approuvé, la publication du blog est planifiée.
 

content/fr/docs/setup/independent/create-cluster-kubeadm.md

@@ -625,7 +625,7 @@ et le contrôle de votre cluster Kubernetes.
 
 ## Feedback {#feedback}
 
-* Pour les bugs, visitez [kubeadm Github issue tracker](https://github.com/kubernetes/kubeadm/issues)
+* Pour les bugs, visitez [kubeadm GitHub issue tracker](https://github.com/kubernetes/kubeadm/issues)
 * Pour le support, rendez vous sur le Channel Slack kubeadm:
   [#kubeadm](https://kubernetes.slack.com/messages/kubeadm/)
 * Le Channel Slack: General SIG Cluster Lifecycle Development:

content/it/community/_index.html

@@ -53,7 +53,7 @@ su come partecipare</p>
                 <p>Ricevi le ultime notizie e aggiornamenti.</p>
             </div>
             <div>
-                <a href="https://github.com/kubernetes/kubernetes">Github Project</a>
+                <a href="https://github.com/kubernetes/kubernetes">GitHub Project</a>
                 <p>Guarda il progetto e considera di contribuire</p>
             </div>
             <div>

content/ja/docs/setup/independent/create-cluster-kubeadm.md

@@ -568,7 +568,7 @@ control of your Kubernetes cluster.
 
 ## フィードバック {#feedback}
 
-* For bugs, visit [kubeadm Github issue tracker](https://github.com/kubernetes/kubeadm/issues)
+* For bugs, visit [kubeadm GitHub issue tracker](https://github.com/kubernetes/kubeadm/issues)
 * For support, visit kubeadm Slack Channel:
   [#kubeadm](https://kubernetes.slack.com/messages/kubeadm/)
 * General SIG Cluster Lifecycle Development Slack Channel:

content/ko/docs/contribute/_index.md

@@ -27,7 +27,7 @@ weight: 80
   참고하라.
 - SIG Docs _리뷰어_ 는 문서 풀 리퀘스트(pull request) 리뷰하는 일에 관심을 보여서 
   SIG Docs 승안자가 적합한 
-  Github 그룹 및 저장소 내 그룹과 `OWNERS` 파일에 등록한
+  GitHub 그룹 및 저장소 내 그룹과 `OWNERS` 파일에 등록한
   쿠버네티스 조직의 멤버이다. 
 - SIG Docs _승인자_ 는 지속적으로 프로젝트에 기여를 해온 좋은 입지를 가진 멤버이다.
   승인자는 풀 리퀘스트를 머지(merge)할 수 있고,

content/zh/docs/setup/independent/create-cluster-kubeadm.md

@@ -1013,7 +1013,7 @@ control of your Kubernetes cluster. -->
 
 ## Feedback {#feedback}
 
-* For bugs, visit [kubeadm Github issue tracker](https://github.com/kubernetes/kubeadm/issues)
+* For bugs, visit [kubeadm GitHub issue tracker](https://github.com/kubernetes/kubeadm/issues)
 * For support, visit kubeadm Slack Channel:
   [#kubeadm](https://kubernetes.slack.com/messages/kubeadm/)
 * General SIG Cluster Lifecycle Development Slack Channel:
@@ -1032,7 +1032,7 @@ control of your Kubernetes cluster. -->
 
 ## 反馈 {#feedback}
 
-* 如果发现故障，请访问 [kubeadm Github issue tracker](https://github.com/kubernetes/kubeadm/issues)
+* 如果发现故障，请访问 [kubeadm GitHub issue tracker](https://github.com/kubernetes/kubeadm/issues)
 * 如果需要支持，请访问 kubeadm 的 Slack 频道：[#kubeadm](https://kubernetes.slack.com/messages/kubeadm/)
 * 访问 SIG cluster-lifecycle 开发者所使用的 Slack 频道：
   [#sig-cluster-lifecycle](https://kubernetes.slack.com/messages/sig-cluster-lifecycle/)

i18n/de.toml

@@ -61,7 +61,7 @@ other = "Weiterlesen"
 other = "Interested in hacking on the core Kubernetes code base?"
 
 [main_github_view_on]
-other = "Auf Github ansehen"
+other = "Auf GitHub ansehen"
 
 [main_github_create_an_issue]
 other = "Problem berichten"

i18n/en.toml

@@ -61,7 +61,7 @@ other = "Read more"
 other = "Interested in hacking on the core Kubernetes code base?"
 
 [main_github_view_on]
-other = "View On Github"
+other = "View On GitHub"
 
 [main_github_create_an_issue]
 other = "Create an Issue"

i18n/es.toml

@@ -61,7 +61,7 @@ other = "Leer más"
 other = "¿Está interesado en participar en el código base de Kubernetes?"
 
 [main_github_view_on]
-other = "Ver en Github"
+other = "Ver en GitHub"
 
 [main_github_create_an_issue]
 other = "Abrir un Issue"

i18n/fr.toml

@@ -58,7 +58,7 @@ other = "Autres ressources"
 other = "Souhaitez vous contribuer au code de Kubernetes ?"
 
 [main_github_view_on]
-other = "Voir sur Github"
+other = "Voir sur GitHub"
 
 [main_github_create_an_issue]
 other = "Ouvrez un ticket"

i18n/it.toml

@@ -10,7 +10,7 @@ other = "Leggi di più"
 other = "Ti interessa l'hacking sulla base del codice di Kubernetes?"
 
 [main_github_view_on]
-other = "Visualizza su Github"
+other = "Visualizza su GitHub"
 
 [main_github_create_an_issue]
 other = "Crea un issue"

i18n/ja.toml

@@ -11,7 +11,7 @@ other = "続きを読む"
 other = "Kubernetesのコードを編集することに興味がありますか？"
 
 [main_github_view_on]
-other = "Githubで参照する"
+other = "GitHubで参照する"
 
 [main_github_create_an_issue]
 other = "Issue作成"

i18n/no.toml

@@ -10,7 +10,7 @@ other = "Les mer"
 other = "Interessert kode i Kubernetes?"
 
 [main_github_view_on]
-other = "Åpne på Github"
+other = "Åpne på GitHub"
 
 [main_github_create_an_issue]
 other = "Opprett en issue"

layouts/blog/baseof.html

@@ -24,7 +24,7 @@
 						{{ end -}}
 						<a class="widget-link" href="https://kubernetes.io/docs/contribute/start/#write-a-blog-post"><i class="fa fa-edit fab-icon"></i> Submit a Post</a>
 						<a class="widget-link" href="https://twitter.com/kubernetesio"> <i class="fab fa-twitter-square fab-icon"> </i> @Kubernetesio</a>
-						<a class="widget-link" href="https://github.com/kubernetes/kubernetes"> <i class="fab fa-github-square fab-icon"></i> View on Github </a>
+						<a class="widget-link" href="https://github.com/kubernetes/kubernetes"> <i class="fab fa-github-square fab-icon"></i> View on GitHub </a>
 						<a class="widget-link" href="http://slack.k8s.io"><i class="fab fa-slack fab-icon"> </i> #kubernetes-users </a>
 						<a class="widget-link" href="https://stackoverflow.com/questions/tagged/kubernetes"><i class="fab fa-stack-overflow fab-icon"></i> Stack Overflow</a>
 						<a class="widget-link" href="https://discuss.kubernetes.io"><i class="fab fa-discourse fab-icon"></i>Forum</a>