docs: apply suggestions from code review

Co-authored-by: Sarina Canelake <sarina@tcril.org>

docs/how-tos/add-new-event-bus-concrete-implementation.rst

@@ -25,7 +25,7 @@ At a high level, the consumer should be a process that takes the signals and eve
 
 The consumer class then needs to implement ``consume_indefinitely`` loop, which will stay running and listen to events as they come in.
 
-We have included an utility function called `prepare_for_new_work_cycle <https://github.com/openedx/openedx-events/blob/26d1d3b87c8ba56f159ab20072cd231264e870f9/openedx_events/tooling.py#L332-L346>`_ in openedx-events which needs to be called before processing any signal. Currently, it reconnects the db connection if required as well as clears RequestCache and there may be later, more comprehensive changes. These steps mimic some setup/teardown that is normally performed by Django in its request/response based architecture.
+We have included a utility function called `prepare_for_new_work_cycle <https://github.com/openedx/openedx-events/blob/26d1d3b87c8ba56f159ab20072cd231264e870f9/openedx_events/tooling.py#L332-L346>`_ in openedx-events which needs to be called before processing any signal. Currently, it reconnects the db connection if required as well as clears RequestCache and there may be later, more comprehensive changes. These steps mimic some setup/teardown that is normally performed by Django in its request/response based architecture.
 
 Check out `consumer.py <https://github.com/openedx/event-bus-redis/blob/main/edx_event_bus_redis/internal/consumer.py>`_ in the event bus redis implementation.
 

docs/how-tos/create-a-new-event.rst

@@ -186,7 +186,7 @@ The :term:`Event Definition` should be implemented in the corresponding subdomai
         }
     )
 
-- The event definition should be documented using in-line documentation with at lest ``event_type``, ``event_name``, ``event_key_field``, ``event_description``, ``event_data`` and ``event_trigger_repository``. This will help consumers understand the event and react to it. See :doc:`../reference/in-line-code-annotations-for-an-event` for more information.
+- The event definition should be documented using in-line documentation with at least ``event_type``, ``event_name``, ``event_key_field``, ``event_description``, ``event_data`` and ``event_trigger_repository``. This will help consumers understand the event and react to it. See :doc:`../reference/in-line-code-annotations-for-an-event` for more information.
 - The :term:`Event Type` should be unique and follow the naming convention for event types specified in the :doc:`../decisions/0002-events-naming-and-versioning` ADR. This is used by consumers to identify the event.
 - The ``event_name`` should be a constant that is used to identify the event in the code.
 - The ``event_key_field`` should be a field in the payload that uniquely identifies the event. This is used by consumers to identify the event.