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

Signed-off-by: GuessWhoSamFoo <sfoohei@gmail.com>

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:

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]() <!-- 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).

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 >}}
 
@@ -213,10 +213,10 @@ documentation.
     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**: 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
@@ -231,11 +231,11 @@ documentation.
     **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**: 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
@@ -246,7 +246,7 @@ documentation.
     **Create pull request**.
     
     Congratulations! Your pull request is available in
-      Pull requests](https://github.com/kubernetes/website/pulls).
+    [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**