📖 Update development.md

docs/developers/development.md

@@ -3,7 +3,7 @@
 Developing our provider is quite easy. First, you need to install some base requirements. Second, you need to follow the quickstart documents to set up everything related to Hetzner. Third, you need to configure your tilt set-up. After having done those three steps, you can start developing with the local Kind cluster and the Tilt UI to create one of the different workload clusters that are already pre-configured. 
 ## Install Base requirements
 
-In order to develop with Tilt, there are a few requirements. You can use the following command to check whether the versions of the tools are up-to-date and to install ones that are missing (for both mac & linux): `make install-dev-prerequisites`
+In order to develop with Tilt, there are a few requirements. You can use the following command to check whether the versions of the tools are up-to-date and to install ones that are missing (for both Mac & Linux): `make install-dev-prerequisites`
 
 This ensures the following:
 - clusterctl
@@ -48,7 +48,7 @@ You need to create a ```tilt-settings.json``` file and specify the values you ne
 }
 ```
 
-The whole reference can be found [here](/docs/developers/tilt.md).
+The complete reference can be found [here](/docs/developers/tilt.md).
 ## Developing with Tilt
 
 <p align="center">
@@ -60,14 +60,14 @@ Provider Integration development requires a lot of iteration, and the “build,
 ```shell
 make tilt-up
 ```
-> To access the Tilt UI please go to: `http://localhost:10350`
+> To access the Tilt UI, please go to: `http://localhost:10350`
 
 
-Once your kind management cluster is up and running, you can deploy a workload cluster. This could be done through the Tilt UI, by pressing one of the buttons in the top right corner, e.g. "Create Workload Cluster - without Packer". This triggers the `make create-workload-cluster`, which uses the environment variables (we defined in the tilt-settings.json) and the cluster-template. Additionally, it installs cilium as CNI.
+Once your kind management cluster is up and running, you can deploy a workload cluster. This could be done through the Tilt UI by pressing one of the buttons in the top right corner, e.g., **"Create Workload Cluster - without Packer"**. This triggers the `make create-workload-cluster` command, which uses the environment variables (we defined in the tilt-settings.json) and the cluster-template. Additionally, it installs cilium as CNI.
 
-If you update the API in some way, you need to run `make generate` in order to generate everything related to kubebuilder and the CRDs.
+If you update the API in some way, you need to run `make generate` to generate everything related to kubebuilder and the CRDs.
 
-To tear down the workload cluster press the "Delete Workload Cluster" button. After a few minutes the resources should be deleted. 
+To tear down the workload cluster, press the **"Delete Workload Cluster"** button. After a few minutes, the resources should be deleted. 
 
 To tear down the kind cluster, use:
 
@@ -77,19 +77,19 @@ $ make delete-mgt-cluster
 
 To delete the registry, use: `make delete-registry` or `make delete-mgt-cluster-registry`.
 
-If you have any trouble finding the right command, then you can use `make help` to get a list of all available make targets. 
+If you have any trouble finding the right command, you can run the `make help` command to get a list of all available make targets. 
 
 ## Submitting PRs and testing
 
-Pull requests and issues are highly encouraged! For more information, please have a look in the [Contribution Guidelines](../../CONTRIBUTING.md)
+Pull requests and issues are highly encouraged! For more information, please have a look at the [Contribution Guidelines](../../CONTRIBUTING.md)
 
 There are two important commands that you should make use of before creating the PR.
 
-With `make verify` you can run all linting checks and others. Make sure that all of these checks pass - otherwise the PR cannot be merged. Note that you need to commit all changes for the last checks to pass. 
+With `make verify`, you can run all linting checks and others. Make sure that all of these checks pass - otherwise, the PR cannot be merged. Note that you need to commit all changes for the last checks to pass. 
 
-With `make test` all unit tests are triggered. If they fail out of nowhere, then please re-run them. They are not 100% stable and sometimes there are tests failing due to something related to Kubernetes' `envtest`.
+With `make test`, all unit tests are triggered. If they fail out of nowhere, then please re-run them. They are not 100% stable and sometimes there are tests failing due to something related to Kubernetes' `envtest`.
 
-With `make generate` new CRDs are generated, this is necessary if you change the api.
+With `make generate`, new CRDs are generated. This is necessary if you change the API.
 ### Running local e2e test
 
 If you are interested in running the E2E tests locally, then you can use the following commands:
@@ -103,7 +103,7 @@ export HETZNER_SSH_PRIV=<your-ssh-private-key>
 make test-e2e
 ```
 
-For the ssh public and private key, you should use the following command to encode the keys. Note that the E2E test will not work if the ssh key is in any other format!
+For the SSH public and private keys, you should use the following command to encode the keys. Note that the E2E test will not work if the ssh key is in any other format!
 ```
 export HETZNER_SSH_PRIV=$(cat ~/.ssh/cluster | base64 -w0)
-```
+```