kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fix indentation and Code of Conduct link in contribute section (#9896) 

Signed-off-by: GuessWhoSamFoo <sfoohei@gmail.com>
This commit is contained in:
Sam Foo 2018-08-18 06:51:06 -07:00 committed by k8s-ci-robot
parent 18ba9a10f4
commit 13184cac84
3 changed files with 39 additions and 39 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/en/docs/concepts/workloads/pods/pod-lifecycle.md
View File

@ -192,7 +192,7 @@ status:
The new Pod conditions must comply with Kubernetes [label key format](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set).
Since the `kubectl patch` command still doesn't support patching object status,
the new Pod conditions have to be injected through the `PATCH` action using
one of the [KubeClient libraries](/docs/reference/using-api/client-librarie/).
one of the [KubeClient libraries](/docs/reference/using-api/client-libraries/).
With the introduction of new Pod conditions, a Pod is evaluated to be ready **only**
when both the following statements are true:

14
content/en/docs/contribute/intermediate.md
View File

@ -61,7 +61,7 @@ active participants.
Before you start reviewing PRs, make sure you are familiar with the
[Documentation Style Guide](/docs/contribute/style/style-guide/)
and the [code of conduct]() <!-- TODO when #9355 is merged -->
and the [code of conduct](/community/code-of-conduct/)
### Find a PR to review
@ -340,7 +340,7 @@ but the following guidelines apply:
use the pre-release feature branch created for that Kubernetes version.
For more guidance, see
[Choose which branch to use](docs/contribute/start#choose-which-git-branch-to-use).
[Choose which branch to use](/docs/contribute/start/#choose-which-git-branch-to-use).
After you decide which branch to start your work (or _base it on_, in Git
terminology), use the following workflow to be sure your work is based on the
@ -387,11 +387,11 @@ most up-to-date version of that branch.
```
{{< note >}}
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.
{{< /note >}}
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.
{{< /note >}}
5. Optionally, you can test your change by staging the site locally using the
`hugo` command. See [View your changes locally](#view-your-changes-locally).

62
content/en/docs/contribute/start.md
View File

@ -147,7 +147,7 @@ need more background in Git terminology.
{{< note >}}
**Kubnetes code developers**: If you are documenting a new feature for an
upcoming Kubernetes release, your process is a bit different. See
[Document a feature](/docs/contribute/intermediate.md#sig-members-documenting-new-features) for
[Document a feature](/docs/contribute/intermediate/#sig-members-documenting-new-features) for
process guidelines and information about deadlines.
{{< /note >}}
@ -197,30 +197,30 @@ documentation.
A new page appears, with some help text.
2. Click the first blue button, which has the text **Edit <page name>**.
If you have never created a fork of the Kubernetes documentation
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.
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.
If you have never created a fork of the Kubernetes documentation
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.
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.
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 >}}
**Note**: 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 >}}
{{< note >}}
**Note**: 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 >}}
Click **Propose file change**. The change is saved as a commit in a
new branch in your fork, which is automatically named something like
`patch-1`.
Click **Propose file change**. The change is saved as a commit in a
new branch in your fork, which is automatically named something like
`patch-1`.
4. The next screen summarizes the changes you made, by comparing your new
branch (the **head fork** and **compare** selection boxes) to the current
@ -230,12 +230,12 @@ documentation.
viewer on the bottom of the screen, and if everything looks right, click
**Create pull request**.
{{< note >}}
**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
pull request if it detects that you pushed a new branch to your fork.
{{< /note >}}
{{< note >}}
**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
pull request if it detects that you pushed a new branch to your fork.
{{< /note >}}
5. The **Open a pull request** screen appears. The subject of the pull request
is the same as the commit summary, but you can change it if needed. The
@ -245,13 +245,13 @@ documentation.
**Allow edits from maintainers** checkbox selected. Click
**Create pull request**.
Congratulations! Your pull request is available in
Pull requests](https://github.com/kubernetes/website/pulls).
After a few minutes, you can preview the website with your PR's changes
applied. Go to the **Conversation** tab of your PR and click the **Details**
link for the `deploy/netlify` test, near the bottom of the page. It opens in
the same browser window by default.
Congratulations! Your pull request is available in
[Pull requests](https://github.com/kubernetes/website/pulls).
After a few minutes, you can preview the website with your PR's changes
applied. Go to the **Conversation** tab of your PR and click the **Details**
link for the `deploy/netlify` test, near the bottom of the page. It opens in
the same browser window by default.
6. Wait for review. Generally, reviewers are suggested by the `k8s-ci-robot`.
If a reviewer asks you to make changes, you can go to the **Files changed**