Documentation updates

This PR updates the documentation and fixes minor nits

Signed-off-by: Krishna Harsha Voora <[email protected]>

docs/contributing/index.md

@@ -9,16 +9,15 @@ For submitting a change upstream, please fork the repository and clone your fork
 $ git clone http://github.com/YOUR-USERNAME/kube-burner
 $ cd kube-burner
 $ git checkout -b <branch_name>
-$ <make change>
+$ make all
 $ git add <changes>
-$ git commit -a
-$ <insert good message>
+$ git commit -m -s "<Details of the Commit>"
 $ git push
 ```
 
 ## CI and Linting
 
-For running pre-commit checks on your code before comitting code and opening a PR, you can use the `pre-commit run` functionality.  See [CI docs](https://cloud-bulldozer.github.io/kube-burner/latest/contributing/ci) for more information.
+For running pre-commit checks on your code before comitting code and opening a PR, you can use the `pre-commit run` functionality.  See [CI docs](https://cloud-bulldozer.github.io/kube-burner/latest/contributing/pullrequest/#running-local-pre-commit) for more information on running pre-commits.
 
 ## Building
 

docs/contributing/tests.md

@@ -4,7 +4,7 @@ Tests are orchestrated using [BATS](https://bats-core.readthedocs.io/en/stable/)
 
 #### Test K8s
 
-For testing kube-burner on a real k8s environment, we use [Kind](https://kind.sigs.k8s.io/), with different K8s versions.
+For testing kube-burner on a real k8s environment, we use [kind](https://kind.sigs.k8s.io/), with different K8s versions.
 
 It creates a quick k8s deployment using containers with podman.
 

docs/observability/alerting.md

@@ -42,7 +42,7 @@ i.e:
 
 ## Checking alerts
 
-It is possible to look for alerts without triggering a kube-burner workload by using the `check-alerts` [subcommand](/cli/#check-alerts). Similar to the `index` CLI option, this option accepts the flags `--start` and `--end` to evaluate the alerts at a given time range.
+It is possible to look for alerts without triggering a kube-burner workload by using the `check-alerts` [subcommand](https://cloud-bulldozer.github.io/kube-burner/latest/cli/#check-alerts). Similar to the `index` CLI option, this option accepts the flags `--start` and `--end` to evaluate the alerts at a given time range.
 
 ```shell
 $ kube-burner check-alerts -u https://prometheus.url.com -t ${token} -a alert-profile.yml

docs/ocp.md

@@ -136,9 +136,9 @@ Note: this workload calculates the number of iterations to create from the numbe
 
 ## Reporting mode
 
-This mode can be enabled with the flag `--reporting`. By enabling this mode kube-burner will a metrics-profile and will index the [aggregated values of the defined timeseries](/kube-burner/metrics/observability/metrics/#aggregating-timeseries-into-a-single-document), and will index only the pod latency quantiles documents (`podLatencyQuantilesMeasurement`) rather than the full pod timeseries.
+This mode can be enabled with the flag `--reporting`. By enabling this mode kube-burner will create a metrics-profile and will index the [aggregated values of the defined timeseries](/kube-burner/metrics/observability/metrics/#aggregating-timeseries-into-a-single-document), and will index only the pod latency quantiles documents (`podLatencyQuantilesMeasurement`) rather than the full pod timeseries.
 
-This feature is very useful to avoid sending thousands of documents to the configured indexer, as only a few documents will be indexed per benchmark. The metrics profile used by this feature is defined in [metrics-report.yml](https://github.com/cloud-bulldozer/kube-burner/cmd/ocp-config/metrics-report.yml))
+This feature is very useful to avoid sending thousands of documents to the configured indexer, as only a few documents will be indexed per benchmark. The metrics profile used by this feature is defined in [metrics-report.yml](https://github.com/cloud-bulldozer/kube-burner/blob/master/cmd/kube-burner/ocp-config/metrics-report.yml))
 
 ## Customizing workloads