Normalize case: Github -> GitHub (#13828)
This commit is contained in:
Danny Berger
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
5ffd272aef
commit
4029a7ab5e
@@ -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
|
||||
|
||||
@@ -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).
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
in the Github issue (adding a comment with `@<Github-username>`) or by sending them the link directly,
|
||||
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,
|
||||
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
|
||||
add new members to a Github group.
|
||||
GitHub group. Only members of the `kubernetes-website-admins` GitHub group can
|
||||
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
|
||||
add new members to a Github group.
|
||||
GitHub group. Only members of the `kubernetes-website-admins` GitHub group can
|
||||
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
|
||||
|
||||
@@ -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
|
||||
instead of using the Github UI. Some basics about using the command-line Git
|
||||
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
|
||||
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
|
||||
|
||||
Reference in New Issue
Block a user