fix: typos

docs/maintainers/handbook.md

@@ -17,7 +17,7 @@ You can run `abra recipe new <recipe>` to generate a new `~/.abra/recipes/<recip
     "unconfigured" healthcheck behaviour is much less strict and it's faster to
     get something up and running.
 
-If you want to make changes to an existing recipe then you can simply edit the files in `~/.abra/recipes/<recipe-name>` and run pass `--chaos` to the `deploy` command when deploying those changes. `abra` will not deploy unstaged changes to avoid instability but you can tell it to do so with `--chaos`. This means ou can simple hack away on the existing recipe files on your local file system and then when something is working, submit a change request to the recipe upstream.
+If you want to make changes to an existing recipe then you can simply edit the files in `~/.abra/recipes/<recipe-name>` and run pass `--chaos` to the `deploy` command when deploying those changes. `abra` will not deploy unstaged changes to avoid instability but you can tell it to do so with `--chaos`. This means you can simply hack away on the existing recipe files on your local file system and then when something is working, submit a change request to the recipe upstream.
 
 ## How is a recipe structured?
 

docs/maintainers/tutorial.md

@@ -14,7 +14,7 @@ Depending on your familiarity with recipes, it might be worth reading [how a rec
 
 ### Making a plan
 
-The idea scenario is when the upstream project provides both the packaged image and a compose configuration which we can build from. If you're in luck, you'll typically find a `Dockerfile` and a `docker-compose.yml` file in the root of the upstream Git repository for the app.
+The ideal scenario is when the upstream project provides both the packaged image and a compose configuration which we can build from. If you're in luck, you'll typically find a `Dockerfile` and a `docker-compose.yml` file in the root of the upstream Git repository for the app.
 
 - **Tired**: Write your own image and compose file from scratch
 - **Wired**: Use someone else's image (& maybe compose file)
@@ -43,9 +43,9 @@ wget https://raw.githubusercontent.com/matomo-org/docker/master/.examples/apache
 
 Open the `compose.yml` in your favourite editor and have a gander 🦢. There are a few things we're looking for, but some immediate changes could be:
 
-1. Let's bump the version to `3.8`, to make sure we can use all the latest swarm coolness
-2. We load environment variables separately via [`abra`](/abra/), so we'll strip out `env_file`
-3. The `/var/www/html` volume definition on L21 is a bit overzealous; it means a copy of Matomo will be stored separately per app instance, which is a waste of space in most cases. We'll narrow it down according to the documentation. The developers have been nice enough to suggest `logs` and `config` volumes instead, which is a decent start
+1. Let's bump the version to `3.8`, to make sure we can use all the latest swarm coolness.
+2. We load environment variables separately via [`abra`](/abra/), so we'll strip out `env_file`.
+3. The `/var/www/html` volume definition on L21 is a bit overzealous; it means a copy of Matomo will be stored separately per app instance, which is a waste of space in most cases. We'll narrow it down according to the documentation. The developers have been nice enough to suggest `logs` and `config` volumes instead, which is a decent start.
 4. The MySQL passwords are sent as variables which is fine for basic use, but if we replace them with Docker secrets we can keep them out of our env files if we want to publish those more widely.
 5. The MariaDB service doesn't need to be exposed to the internet, so we can define an `internal` network for it to communicate with Matomo.
 6. Lastly, we want to use `deploy.labels` and remove the `ports:` definition, to tell Traefik to forward requests to Matomo based on hostname and generate an SSL certificate.