Fix indentation everywhere, hugo sucks sometimes

Signed-off-by: Maël Valais <mael@vls.dev>

Author: maelvls

content/en/docs/contributing/release-process.md

@@ -72,145 +72,151 @@ The process for cutting a minor release is as follows:
 
 2. Create or update the release branch
 
- If this is the first alpha release (`alpha.0`), then you will need to create
- the release branch:
+  If this is the first alpha release (`alpha.0`), then you will need to create
+  the release branch:
 
- ```bash
- git fetch --all
- git checkout -b release-1.0 origin/master
- ```
+  ```bash
+  git fetch --all
+  git checkout -b release-1.0 origin/master
+  ```
 
- If there has already been an alpha release, the release branch will
- already exist, so you will need to update it with the latest commits
- from the master branch, as follows:
+  If there has already been an alpha release, the release branch will
+  already exist, so you will need to update it with the latest commits
+  from the master branch, as follows:
 
- ```bash
- git fetch --all
- git branch --force release-1.0 origin/release-1.0
- git checkout release-1.0
- git merge --ff-only origin/master
- ```
+  ```bash
+  git fetch --all
+  git branch --force release-1.0 origin/release-1.0
+  git checkout release-1.0
+  git merge --ff-only origin/master
+  ```
 
 3. Push it to the `jetstack/cert-manager` repository
 
- > Note: make sure that the `origin` remote points to the upstream <https://github.com/jetstack/cert-manager.git> with `git remote -v`.
+ Note 1: run `git remote -v` to check that `origin` points to the
+ upstream <https://github.com/jetstack/cert-manager.git>.
 
- > Note 2: uou need to be an "admin" of the GitHub project to be able to
- > push to the release branch.
+   Note 2: uou need to be an "admin" of the GitHub project to be able to
+   push to the release branch.
 
- ```bash
- git push --set-upstream origin
- ```
+  ```bash
+  git push --set-upstream origin
+  ```
 
 4. Generate and edit the release notes:
 
  1. Run as follows, substituting the current and last versions where appropriate:
 
- ```bash
- export GITHUB_TOKEN=*your-token*
- export RELEASE_VERSION=1.0.0
- export BRANCH=release-1.0
- export END_REV=release-1.0
- export START_REV=v0.16.1
- (cd && GO111MODULE=on go get k8s.io/release/cmd/release-notes@v0.7.0)
- release-notes --repo cert-manager --org jetstack --required-author "jetstack-bot" --output release-notes.md --repo-path cert-manager --debug
- ```
-
- > Note: the GitHub token does not need any scope. The token is
- required only to avoid rate-limits imposed on anonymous API users.
+ ```bash
+ export GITHUB_TOKEN=*your-token*
+ export RELEASE_VERSION=1.0.0
+ export BRANCH=release-1.0
+ export END_REV=release-1.0
+ export START_REV=v0.16.1
+ (cd && GO111MODULE=on go get k8s.io/release/cmd/release-notes@v0.7.0)
+ release-notes --debug --repo-path cert-manager \
+ --org jetstack --repo cert-manager \
+ --required-author "jetstack-bot" \
+ --output release-notes.md
+ ```
+
+ Note: the GitHub token does not need any scope. The token is
+ required only to avoid rate-limits imposed on anonymous API users.
 
  2. Sanity check the notes, checking that the notes contain details of all
  the features and bug fixes that you expect to be in the release. Add
  additional blurb, notable items and characterize change log.
 
- You can see the commits that will go into this release by using the
- [GitHub compare](https://github.com/jetstack/cert-manager/compare). For
- example, while releasing `v1.0.0`, you want to compare it with the
- latest pre-released version `v1.0.0-beta.1`:
+  You can see the commits that will go into this release by using the
+  [GitHub compare](https://github.com/jetstack/cert-manager/compare). For
+  example, while releasing `v1.0.0`, you want to compare it with the
+  latest pre-released version `v1.0.0-beta.1`:
 
- > <https://github.com/jetstack/cert-manager/compare/v1.0.0-beta.1...master>
+   <https://github.com/jetstack/cert-manager/compare/v1.0.0-beta.1...master>
 
 
 5. Run `cmrel stage`
 
  1. In this example we stage a release using the 'release-1.0' branch,
  setting the release version to `v1.0.0`:
 
- ```bash
- cmrel stage --branch=release-1.0 --release-version=v1.0.0
- ```
+  ```bash
+  cmrel stage --branch=release-1.0 --release-version=v1.0.0
+  ```
 
- This step takes ~10 minutes. It will build all Docker images and
- create all the manifest files and upload them to a storage bucket on
- Google Cloud. These artifacts will be published and released in the
- next steps.
+  This step takes ~10 minutes. It will build all Docker images and
+  create all the manifest files and upload them to a storage bucket on
+  Google Cloud. These artifacts will be published and released in the
+  next steps.
 
- The final line of output contains URL of the bucket
- containing the release artifacts. The final segment in that URL
- contains the `RELEASE_NAME`, which you will need in the next step.
+  The final line of output contains URL of the bucket containing the
+   release artifacts. The final segment in that URL contains the
+   `RELEASE_NAME`, which you will need in the next step.
 
  2. While the build is running, send a first Slack message to
  `#cert-manager-dev`:
 
- > Releasing `1.2.0-alpha.2` 🧵
+  _Releasing `1.2.0-alpha.2` 🧵_
 
- ⚠️ Please have a quick look at the build log as it might contain some
- unredacted data that we forgot to redact. We try to make sure the
- sensitive data is properly redacted but sometimes we forget to update
- this.
+  ⚠️ Note: please have a quick look at the build log as it might
+  contain some unredacted data that we forgot to redact. We try to
+  make sure the sensitive data is properly redacted but sometimes we
+  forget to update this.
 
  3. Send a second Slack message in reply to this first message with the
  Cloud Build job link that `cmrel` displayed in "View logs at". For
  example, the message would look like:
 
- > Stage step: <https://console.cloud.google.com/cloud-build/builds/7641734d-fc3c-42e7-9e4c-85bfc4d1d547?project=1021342095237>
+  _Follow the cmrel stage build: <https://console.cloud.google.com/cloud-build/builds/7641734d-fc3c-42e7-9e4c-85bfc4d1d547?project=1021342095237>_
 
 6. Run `cmrel publish`
 
  1. First do a dry-run, to ensure that all the staged resources are valid.
 
- ```bash
- cmrel publish --release-name <RELEASE_NAME>
- ```
+  ```bash
+  cmrel publish --release-name <RELEASE_NAME>
+  ```
 
  Where `<RELEASE_NAME>` is the unique build ID printed by the earlier `cmrel stage` command.
- E.g. Given `gs://cert-manager-release/stage/gcb/release/v1.0.0-219b7934ac499c7818526597cf635a922bddd22e`,
- the `RELEASE_NAME` would be `v1.0.0-219b7934ac499c7818526597cf635a922bddd22e`.
+
+ For example, given the bucket
+ `gs://cert-manager-release/stage/gcb/release/v1.0.0-219b793`, the
+ `RELEASE_NAME` would be `v1.0.0-219b793`.
 
  You can view the progress by clicking the Google Cloud Build URL in the output of this command.
 
  2. While the build is running, send a third Slack message in reply to
  the first message:
 
- > Publish dry-run step: <https://console.cloud.google.com/cloud-build/builds/16f6f875-0a23-4fff-b24d-3de0af207463?project=1021342095237>
+  _Follow the cmrel publish dry-run build: <https://console.cloud.google.com/cloud-build/builds16f6f875-0a23-4fff-b24d-3de0af207463?project=1021342095237>_
 
  3. Next publish the release artifacts for real.
 
- If the last step succeeded, you can now re-run the `cmrel publish`
- with the `--nomock` argument to actually publish the release
- artifacts to GitHub, `Quay.io`, [ArtifactHub][] etc.
+  If the last step succeeded, you can now re-run the `cmrel publish`
+  with the `--nomock` argument to actually publish the release
+  artifacts to GitHub, `Quay.io`, [ArtifactHub][] etc.
 
- ```bash
- cmrel publish --nomock --release-name <RELEASE_NAME>
- ```
+  ```bash
+  cmrel publish --nomock --release-name <RELEASE_NAME>
+  ```
 
- NOTE: At this stage there will be a draft release on GitHub and a
- live release on [ArtifactHub][]. So you must now complete the release
- process quickly otherwise users of the latest release on
- [ArtifactHub][] will encounter errors, because the manual CRD install
- URL will not be available yet.
+  Note: At this stage there will be a draft release on GitHub and a
+  live release on [ArtifactHub][]. So you must now complete the
+  release process quickly otherwise users of the latest release on
+  [ArtifactHub][] will encounter errors, because the manual CRD
+  install URL will not be available yet.
 
  4. While the build is running, send a fourth Slack message in reply to
  the first message:
 
- > Publish step: <https://console.cloud.google.com/cloud-build/builds/b6fef12b-2e81-4486-9f1f-d00592351789?project=1021342095237>
+  _Follow the cmrel publish build: <https://console.cloud.google.com/cloud-build/builds/b6fef12b-2e81-4486-9f1f-d00592351789?project=1021342095237>_
 
 7. Publish the GitHub release
 
  1. Visit the draft GitHub release and paste in the release notes that you generated earlier.
 
- You will need to manually edit the content to match the style of earlier releases.
- In particular, remember to remove package-related changes.
+  You will need to manually edit the content to match the style of earlier releases.
+  In particular, remember to remove package-related changes.
 
  2. Tick the box "This is a pre-release" if your release is an alpha.
  (not necessary for final releases)
@@ -222,7 +228,7 @@ The process for cutting a minor release is as follows:
  the check box "Also send to `#cert-manager-dev`" so that the message is
  well visible. Also cross-post the message on `#cert-manager`.
 
- > <https://github.com/jetstack/cert-manager/releases/tag/v1.0.0> 🎉
+  _<https://github.com/jetstack/cert-manager/releases/tag/v1.0.0> 🎉_
 
 ### Final Release