From 13184cac84c6c77614221170de27c02fed568344 Mon Sep 17 00:00:00 2001 From: Sam Foo Date: Sat, 18 Aug 2018 06:51:06 -0700 Subject: [PATCH] Fix indentation and Code of Conduct link in contribute section (#9896) Signed-off-by: GuessWhoSamFoo --- .../concepts/workloads/pods/pod-lifecycle.md | 2 +- content/en/docs/contribute/intermediate.md | 14 ++--- content/en/docs/contribute/start.md | 62 +++++++++---------- 3 files changed, 39 insertions(+), 39 deletions(-) diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md index ed9af77d0e..85c052466c 100644 --- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md @@ -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: diff --git a/content/en/docs/contribute/intermediate.md b/content/en/docs/contribute/intermediate.md index 7984e9c5eb..3166dcca53 100644 --- a/content/en/docs/contribute/intermediate.md +++ b/content/en/docs/contribute/intermediate.md @@ -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]() +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). diff --git a/content/en/docs/contribute/start.md b/content/en/docs/contribute/start.md index 7929f21584..0a18d01644 100644 --- a/content/en/docs/contribute/start.md +++ b/content/en/docs/contribute/start.md @@ -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 **. - 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//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//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**