Update contributor docs

	- Explain kured code structure
	- Update links, as some docs have moved
	- Readability and fix typos

Signed-off-by: Daniel Holbach <daniel.holbach@gmail.com>

CONTRIBUTING.md

@@ -5,13 +5,13 @@ Slack][slack], reporting or triaging [issues][issues] or contributing code
 to `kured`.
 
 In any case, it will make sense to familiarise yourself with the main
-[README][readme] to understand the different features and options, which is
-helpful for testing. The "building" section in particular makes sense if
-you are planning to contribute code.
+[documentation][documentation] to understand the different features and
+options, which is helpful for testing. The "building" section in
+particular makes sense if you are planning to contribute code.
 
 [slack]: README.md#getting-help
 [issues]: https://github.com/kubereboot/kured/issues
-[readme]: README.md
+[documentation]: https://kured.dev/docs
 
 ## Certificate of Origin
 
@@ -41,6 +41,15 @@ All Kured repositories are kept under <https://github.com/kubereboot>. To find t
 | <https://github.com/kubereboot/charts>  | Helm chart                |
 | <https://github.com/kubereboot/website> | website and documentation |
 
+### Kured code
+
+- Kured's main code can be found in the [`cmd`](cmd) and [`pkg`](pkg) directories
+- Its smoke tests are in the [`tests`](tests) directory
+- We use [GoReleaser to build](.goreleaser.yml).
+- Every PR and tagged release is tested by [Kind in GitHub workflows](.github/workflows).
+
+As a project, we try to follow all the official and obvious standards.
+
 ## Regular development activities
 
 ### Prepare environment
@@ -70,12 +79,12 @@ Please update our `.github/workflows` with the new k8s images, starting by
 the creation of a `.github/kind-cluster-<version>.yaml`, then updating
 our workflows with the new versions.
 
-Once you updated everything, make sure you update the support matrix on
-the main [README][readme] as well.
+Once you updated everything, make sure you update the support matrix in
+the [installation docs](https://kured.dev/docs/installation/) as well.
 
 ### Updating other dependencies
 
-Dependabot proposes changes in our go.mod/go.sum.
+Dependabot proposes changes in our `go.mod`/`go.sum`.
 Some of those changes are covered by CI testing, some are not.
 
 Please make sure to test those not covered by CI (mostly the integration
@@ -87,7 +96,7 @@ We run periodic jobs (see also Automated testing section of this documentation).
 Those should be monitored for failures.
 
 If a failure happen in periodics, something terribly wrong must have happened
-(or github is failing at the creation of a kind cluster). Please monitor those
+(or GitHub is failing at the creation of a kind cluster). Please monitor those
 failures carefully.
 
 ### Introducing new features
@@ -107,23 +116,24 @@ This also means that when you expose a new feature, you should create another PR
 for your changes in <https://github.com/kubereboot/charts> to make your feature
 available at the next kured version for helm users.
 
-In the charts PR, you can directly bump the appVersion to the next minor version
+In the charts PR, you can directly bump the `appVersion` to the next minor version
 (you are introducing a new feature, which requires a bump of the minor number.
-For example, if current appVersion is 1.6.x, make sure you update your appVersion
-to 1.7.0). It allows us to have an easy view of what we land each release.
+For example, if current `appVersion` is `1.6.x`, make sure you update your `appVersion`
+to `1.7.0`). It allows us to have an easy view of what we land each release.
 
 Do not hesitate to increase the test coverage for your feature, whether it's unit
-testing to full functional testing (even using helm charts)
+testing to full functional testing (even using helm charts).
 
 ### Increasing test coverage
 
 We are welcoming any change to increase our test coverage.
-See also our github issues for the label `testing`.
+See also our GitHub issues for the label
+[`testing`](https://github.com/kubereboot/kured/labels/testing).
 
 ## Automated testing
 
-Our CI is covered by github actions.
-You can see their contents in .github/workflows.
+Our CI is covered by GitHub actions.
+You can see their contents in `.github/workflows`.
 
 We currently run:
 
@@ -160,7 +170,7 @@ Please run `make test`. You should have `golint` installed.
 
 A test-run with `minikube` could look like this:
 
-```console
+```cli
 # start minikube
 minikube start --driver=kvm2 --kubernetes-version <k8s-release>
 
@@ -192,7 +202,7 @@ Then you can check for the lock release.
 
 A test-run with `kind` could look like this:
 
-```console
+```cli
 # create kind cluster
 kind create cluster --config .github/kind-cluster-<k8s-version>.yaml
 
@@ -208,8 +218,8 @@ kind create cluster --config .github/kind-cluster-<k8s-version>.yaml
 
 ### Prepare Documentation
 
-Check that [compatibility matrix](https://kured.dev/docs/installation/) is updated
-to the new version you want to release.
+Ensure the [compatibility matrix](https://kured.dev/docs/installation/) is
+updated to the new version you want to release.
 
 ### Create a tag on the repo
 
@@ -231,7 +241,7 @@ cat kured-ds.yaml >> "$MANIFEST"
 
 ### Publish release artifacts
 
-Now you can head to the Github UI, use the version number as tag and upload the
+Now you can head to the GitHub UI, use the version number as tag and upload the
 `kured-<release>-dockerhub.yaml` file.
 
 Please describe what's new and noteworthy in the release notes, list the PRs