Fix spelling errors.

docs/explanation/storedstate-uses-limitations.md

@@ -84,7 +84,7 @@ def _on_config_changed(self, event):
 
 One common scenario where charm authors get tempted to use `StoredState`, when a no-op would be better, is to use `StoredState` to cache information from the Juju model. The Operator Framework already caches information about relations, unit and application names, etc. It reads and loads the charm's config into memory during each hook execution. Authors can simply fetch model and config information as needed, trusting that the Operator Framework is avoiding extra work where it can, and doing extra work to avoid cache coherency issues where it must. 
 
-Another temptation is to track the occurence of certain events like [`pebble-ready`](https://juju.is/docs/sdk/events#heading--pebble-ready). This is dangerous. The emission of a `pebble-ready` event means that Pebble was up and running when the hook was invoked, but makes no guarantees about the future. Pebble may not remain running -- see the note about the Kubernetes scheduler above -- meaning your `StoredState` contains an invalid cache value which will likely lead to bugs. In cases where charm authors want to perform an action if and only if the workload container is up and running, they should guard against Pebble issues by catching `ops.pebble.ConnectionError`:
+Another temptation is to track the occurrence of certain events like [`pebble-ready`](https://juju.is/docs/sdk/events#heading--pebble-ready). This is dangerous. The emission of a `pebble-ready` event means that Pebble was up and running when the hook was invoked, but makes no guarantees about the future. Pebble may not remain running -- see the note about the Kubernetes scheduler above -- meaning your `StoredState` contains an invalid cache value which will likely lead to bugs. In cases where charm authors want to perform an action if and only if the workload container is up and running, they should guard against Pebble issues by catching `ops.pebble.ConnectionError`:
 
 ```python
 def some_event_handler(event):
@@ -101,4 +101,4 @@ In the other cases where state is needed, authors ideally want to relate a charm
 
 In the cases where it is important to share some lightweight configuration data between units of an application, charm author's should look into [peer relations](https://juju.is/docs/sdk/integration#heading--peer-integrations). And in the cases where data must be written to a container's local file system (Canonical's Kubeflow bundle, for example, must do this, because the sheer number of services mean that we run into limitations on attached storage in the underlying cloud), authors should do so mindfully, with an understanding of the pitfalls involved.
 
-In sum: use state mindfully, with well chosen tools, only when necessary.
+In sum: use state mindfully, with well chosen tools, only when necessary.

docs/howto/manage-interfaces.md

@@ -462,7 +462,7 @@ Essentially, you need to make it so that the charm runtime 'thinks' that everyth
 This may mean mocking the presence and connectivity of a container, system calls, substrate API calls, and more.
 If you have scenario or unittests in your codebase, you most likely already have all the necessary patches scattered around and it's a matter of collecting them.
 
-Remember that if you run your tests using `run_matrix.py` locally, in your troubleshooting you need to point `interface.yaml` to the branch where you commited your changes as `run_matrix` fetches the charm repositories in order to run the charms:
+Remember that if you run your tests using `run_matrix.py` locally, in your troubleshooting you need to point `interface.yaml` to the branch where you committed your changes as `run_matrix` fetches the charm repositories in order to run the charms:
 
 ```text
 requirers:

docs/howto/run-workloads-with-a-charm-kubernetes.md

@@ -849,7 +849,7 @@ pg_dump mydb >/tmp/mydb.sql
 
 The first argument to `pebble notify` is the key, which must be in the format `<domain>/<path>`. The caller can optionally provide map data arguments in `<name>=<value>` format; this example shows a single data argument named `path`.
 
-The `pebble notify` command has an optional `--repeat-after` flag, which tells Pebble to only allow the notice to repeat after the specified duration (the default is to repeat for every occurrence). If the caller says `--repeat-after=1h`, Pebble will prevent the notice with the same type and key from repeating within an hour -- useful to avoid the charm waking up too often when a notice occcurs frequently.
+The `pebble notify` command has an optional `--repeat-after` flag, which tells Pebble to only allow the notice to repeat after the specified duration (the default is to repeat for every occurrence). If the caller says `--repeat-after=1h`, Pebble will prevent the notice with the same type and key from repeating within an hour -- useful to avoid the charm waking up too often when a notice occurs frequently.
 
 > See more: [GitHub | Pebble > Notices > `pebble notify`](https://github.com/canonical/pebble#notices)
 

docs/howto/write-unit-tests-for-a-charm.md

@@ -23,7 +23,7 @@ def harness():
     # Set a name for the testing model created by Harness (optional).
     # Cannot be called after harness.begin()
     harness.set_model_name("testing")
-    # Instanciate an instance of the charm (harness.charm)
+    # Instantiate an instance of the charm (harness.charm)
     harness.begin()
     yield harness
     # Run Harness' cleanup method on teardown