Tweak spelling/format

proposals/4140-delayed-events-futures.md

@@ -244,7 +244,7 @@ These objects contain the following fields:
   - `delayed_event` - Required. Describes the original delayed event in the same format as the items in the `scheduled` array.
   - `outcome`: `"send"|"cancel"` - Whether the delayed event was sent, or was cancelled by an error or [the management endpoint](#managing-delayed-events) with an `action` of `"cancel"`.
   - `reason`: `"error"|"action"|"delay"` - What caused the delayed event to become finalised. `"error"` means the delayed event failed to be sent due to an error; `"action"` means it was sent or cancelled by [the management endpoint](#managing-delayed-events); and `"delay"` means it was sent automatically on its scheduled delivery time.
-  - `error`: Optional Error. A matrix error (as defined by [Standard error response](https://spec.matrix.org/v1.11/client-server-api/#standard-error-response))
+  - `error` - Optional. A Matrix error (as defined by [Standard error response](https://spec.matrix.org/v1.11/client-server-api/#standard-error-response))
   to explain why this event failed to be sent.
   - `event_id` - Optional. The `event_id` this event got in case it was sent.
   - `origin_server_ts` - Optional. The timestamp of when the event was sent.
@@ -745,7 +745,7 @@ will be stored with the following outcome:
 "reason": "error",
 "error": {
   "errorcode": "M_CANCELLED_BY_STATE_UPDATE",
-  "error":"The delayed event did not get send because a different user updated the same state event.
+  "error":"The delayed event did not get sent because a different user updated the same state event.
   So the scheduled event might change it in an undesired way."
 }
 ```
@@ -759,7 +759,7 @@ The `M_UNKNOWN` `errcode` should be used instead of `M_CANCELLED_BY_STATE_UPDATE
 "error": {
   "errcode": "M_UNKNOWN",
   "org.matrix.msc4140.errcode": "M_CANCELLED_BY_STATE_UPDATE",
-  "error":"The delayed event did not get send because a different user updated the same state event.
+  "error":"The delayed event did not get sent because a different user updated the same state event.
   So the scheduled event might change it in an undesired way."
 }
 ```
@@ -779,10 +779,10 @@ All new endpoints are authenticated.
 To mitigate the risk of users flooding the delayed events database, servers MUST impose limits on the number and
 timeout duration of scheduled delayed events. The exact limits are left as an implementation detail.
 
-It is the server maintainers responsibility to evaluate the best tradeoff between what usecases
+It is the server maintainers responsibility to evaluate the best trade-off between what use cases
 their users have for delayed events for and the resources they are able to provide.
 
-Its the homeserver implementers responsibility to communicate this and educate the server hosters about the tradeoffs
+Its the homeserver implementers responsibility to communicate this and educate the server hosters about the trade-offs
 and potentially give sane example values for those configurations.
 
 As described [above](#power-levels-are-evaluated-at-the-point-of-sending), the homeserver **must** evaluate and enforce the