Fix typos in documentation (#12863)
4 files changed, 4 insertions, 3 deletions
diff --git a/changelog.d/12863.doc b/changelog.d/12863.doc
new file mode 100644
index 0000000000..94f7b8371a
--- /dev/null
+++ b/changelog.d/12863.doc
@@ -0,0 +1 @@
+Fix typos in documentation.
\ No newline at end of file
diff --git a/docs/message_retention_policies.md b/docs/message_retention_policies.md
index 9214d6d7e9..b52c4aaa24 100644
--- a/docs/message_retention_policies.md
+++ b/docs/message_retention_policies.md
@@ -117,7 +117,7 @@ In this example, we define three jobs:
Note that this example is tailored to show different configurations and
features slightly more jobs than it's probably necessary (in practice, a
server admin would probably consider it better to replace the two last
-jobs with one that runs once a day and handles rooms which which
+jobs with one that runs once a day and handles rooms which
policy's `max_lifetime` is greater than 3 days).
Keep in mind, when configuring these jobs, that a purge job can become
diff --git a/docs/structured_logging.md b/docs/structured_logging.md
index a6667e1a11..d43dc9eb6e 100644
--- a/docs/structured_logging.md
+++ b/docs/structured_logging.md
@@ -43,7 +43,7 @@ loggers:
The above logging config will set Synapse as 'INFO' logging level by default,
with the SQL layer at 'WARNING', and will log to a file, stored as JSON.
-It is also possible to figure Synapse to log to a remote endpoint by using the
+It is also possible to configure Synapse to log to a remote endpoint by using the
`synapse.logging.RemoteHandler` class included with Synapse. It takes the
following arguments:
diff --git a/docs/workers.md b/docs/workers.md
index 779069b817..5033722098 100644
--- a/docs/workers.md
+++ b/docs/workers.md
@@ -1,6 +1,6 @@
# Scaling synapse via workers
-For small instances it recommended to run Synapse in the default monolith mode.
+For small instances it is recommended to run Synapse in the default monolith mode.
For larger instances where performance is a concern it can be helpful to split
out functionality into multiple separate python processes. These processes are
called 'workers', and are (eventually) intended to scale horizontally
|