chore: fixed typos.

oeps/architectural-decisions/oep-0003-arch-async-tasks.rst

@@ -110,7 +110,7 @@ Later enhancements will likely include the following:
   contingent on the completion and implementation of another OEP specifically
   for push notifications in Open edX.
 * Support for tasks which can be monitored by multiple users with sufficient
-  access priveleges.  Different permissions could be created for status
+  access privileges.  Different permissions could be created for status
   viewing, generated artifact access, the ability to cancel the task, and the
   ability to delete the task.
 

oeps/architectural-decisions/oep-0006-arch-context-xblock-fields.rst

@@ -140,7 +140,7 @@ as a blog post or a textbook.
 New named scopes
 ================
 
-As is the situtation today, XBlock runtimes would generally not be expected to
+As is the situation today, XBlock runtimes would generally not be expected to
 implement every possible combination of ``BlockScope`` and ``UserScope``.
 Instead, XBlock runtimes are encouraged to implement these new named scopes,
 which would be defined in the XBlock python package:
@@ -308,7 +308,7 @@ Open Questions
 
 #. If yes (see previous bullet), can we use a field attribute to allow XBlocks
    to opt-out of this auto-generated settings UIs on a per-field basis? This may
-   best be addressed at the same time as a standard API for definining editor UI
+   best be addressed at the same time as a standard API for defining editor UI
    options such as ``allow_reset``, ``multiline_editor``, ``list_style``, and
    ``values_provider`` as implemented in `xblock-utils`_.
 

oeps/architectural-decisions/oep-0026-arch-realtime-events.rst

@@ -149,7 +149,7 @@ Eventing Components
 
 While the exact technical framework and tools for supporting real-time events *at scale* is to be determined, we can begin with implementing the various components of the eventing service from a modular perspective so they can be adopted into any scalable infrastructure (e.g., an Apache framework). So while we propose a framework in this section, each subcomponent is expected to be independent and modular so it can be recomposed as needed.
 
-The proposed framework integrates into and builds upon the features of the `Open edX Event Tracking`_ library. The library's RoutingBackend_ provides powerful and flexible tools with its two fundamental building blocks of `processors and backends`_. The diagram below depicts a possibility of using these tools to implement our real-time Eventing subsytem.
+The proposed framework integrates into and builds upon the features of the `Open edX Event Tracking`_ library. The library's RoutingBackend_ provides powerful and flexible tools with its two fundamental building blocks of `processors and backends`_. The diagram below depicts a possibility of using these tools to implement our real-time Eventing subsystem.
 
 .. _Open edX Event Tracking: https://github.com/openedx/event-tracking
 .. _RoutingBackend: https://github.com/openedx/event-tracking/blob/03bedd4c4f269c65f266f7e95621a9c1b91f908d/eventtracking/backends/routing.py#L11
@@ -263,6 +263,6 @@ Here are a list of current Open edX frameworks that are related to "eventing" bu
 
 * **Notifications and messaging framework** - It is also not the intention of this OEP's real-time eventing framework to support real-time messaging to users. The Open edX `Automated Communication Engine (ACE)`_ is a Django library that supports personalized delivery of user-targeted messages. It is a pluggable and modular framework that supports multiple delivery channels with theme-aware and user-language-aware message templates.
 
-  Although it is possible for this OEP's real-time eventing framwork to send events targeted to IoT and personal devices, those events will not be translated nor customized for each individual recipient, nor be adaptive to the individual's policies and time sensitivities. ACE would be a better alternative for those requirements.
+  Although it is possible for this OEP's real-time eventing framework to send events targeted to IoT and personal devices, those events will not be translated nor customized for each individual recipient, nor be adaptive to the individual's policies and time sensitivities. ACE would be a better alternative for those requirements.
 
 .. _Automated Communication Engine (ACE): https://edx-ace.readthedocs.io/en/latest/index.html

oeps/architectural-decisions/oep-0026/caliper-realtime-events.rst

@@ -10,7 +10,7 @@ Caliper Real-time Events
 Standardized Integration with Caliper
 *************************************
 
-Caliper Analtyics® is a specification defining "a structured approach to describing, collecting and exchanging learning activity data. Establishing a common vocabulary for describing learning interactions is a central objective. Promoting data interoperability, data sharing and data-informed decision making are also important goals."[#caliperDesignGoals]_  The standard has been described as "common-gauge rail for disparate applications to use and share data from student interactions with learning software and administrative systems."[#commonGaugeRail]_
+Caliper Analytics® is a specification defining "a structured approach to describing, collecting and exchanging learning activity data. Establishing a common vocabulary for describing learning interactions is a central objective. Promoting data interoperability, data sharing and data-informed decision making are also important goals."[#caliperDesignGoals]_  The standard has been described as "common-gauge rail for disparate applications to use and share data from student interactions with learning software and administrative systems."[#commonGaugeRail]_
 
 Caliper Learning Analytics Ecosystem
 ************************************

oeps/architectural-decisions/oep-0031-arch-i18n.rst

@@ -218,7 +218,7 @@ There is a special accessibility use case where a message ID doesn't have a tran
 Currency localization
 =====================
 
-We should correctly localize currency, which is an issue of country rather than language, and reliant on having an accurate currency conversion service.  This is beyond the scope of our i18n libary.
+We should correctly localize currency, which is an issue of country rather than language, and reliant on having an accurate currency conversion service.  This is beyond the scope of our i18n library.
 
 ======================
 Consistent terminology

oeps/architectural-decisions/oep-0032-arch-unique-identifier-for-users.rst

@@ -79,7 +79,7 @@ The following table summarizes the comparisons of a list of candidate user ident
    * - LMS user_id
      - * anonymous (is not considered PII)
 
-       * Segment (used for anlytics) recommends database IDs because they never change.
+       * Segment (used for analytics) recommends database IDs because they never change.
 
        * Availability across all services is almost, but not yet complete.
 

oeps/architectural-decisions/oep-0041-arch-async-server-event-messaging.rst

@@ -326,7 +326,7 @@ Likewise, use ``updated_at`` for database updates. Do
 that are just a few milliseconds offset from the database record of these
 actions. Do call ``datetime.now()`` if the event happens and has no
 corresponding database changes. If you are sending out multiple event messages
-describing the same occurance (e.g. a version 1 and version 2 of an event), they
+describing the same occurrence (e.g. a version 1 and version 2 of an event), they
 should have the *exact* same timestamp.
 
 
@@ -388,7 +388,7 @@ ability to control its own load. For instance, a sudden increase in Courseware
 traffic might generate a burst of student analytics events. If this stream of
 events overwhelms your service's ability to consume them, the queue may start to
 back up with unread events. Yet this shouldn't cause your service to fail, since
-it still gets to control how quicky it consumes events off of that queue. It has
+it still gets to control how quickly it consumes events off of that queue. It has
 the freedom to either slowly catch up (if the burst was a momentary spike), or
 to scale up additional workers to handle the higher throughput. Your service's
 decision to scale up or down does not directly impact other services.
@@ -421,7 +421,7 @@ be expired by the time a consumer gets them.
 Architectural Goals
 ===================
 
-This OEP is strongly aligned with the `Achitecture Manifesto
+This OEP is strongly aligned with the `Architecture Manifesto
 <https://openedx.atlassian.net/l/c/wN425om2>`_ themes of decentralization and
 asynchronous communication. In addition, there are a number of specific pain
 points we hope to address by introducing this kind of system.

oeps/architectural-decisions/oep-0045/decisions/0001-tutor-as-replacement-for-edx-configuration.rst

@@ -241,7 +241,7 @@ Open edX development environment.
 Support for master
 ------------------
 
-Like the production version, Tutor does not currently support runnning the ``master`` branch of ``edx-platform`` for
+Like the production version, Tutor does not currently support running the ``master`` branch of ``edx-platform`` for
 development.
 
 Setup procedure

oeps/architectural-decisions/oep-0045/decisions/0002-helm-for-multi-instance-k8s.rst

@@ -30,7 +30,7 @@ For Open edX operators who wish to deploy Open edX on Kubernetes, community-main
 
 Building on top of the `decision 0001`_ those single instances will in turn be managed by Tutor and the Tutor plugin ecosystem.
 
-As the needs and deployment scale of Open edX operators can vary significantly, the Helm charts will be designed to be flexible, incorporating sensible defaults but allowing customization of almost every aspect of the deployment. This includes supporting various cloud providers and different underlying technologies for Kubernetes ressources. E.g. Ingress controllers.
+As the needs and deployment scale of Open edX operators can vary significantly, the Helm charts will be designed to be flexible, incorporating sensible defaults but allowing customization of almost every aspect of the deployment. This includes supporting various cloud providers and different underlying technologies for Kubernetes resources. E.g. Ingress controllers.
 
 The goal is for these Helm charts to be developed and maintained collaboratively, by the Open edX Operators that are using them. All relevant best practices from both the Open edX and Helm projects should be followed from the start, such as `OEP-55 Project Maintainers`_.
 
@@ -104,7 +104,7 @@ Once this ADR has reached Provisional status:
 References
 **********
 
-A `working proof of concept`_ that was writen as part of the research for this ADR. See `2022-11-22 meeting recap`_ for further information.
+A `working proof of concept`_ that was written as part of the research for this ADR. See `2022-11-22 meeting recap`_ for further information.
 
 .. _`working proof of concept`: https://github.com/open-craft/tutor-contrib-multi
 .. _`2022-11-22 meeting recap`: https://discuss.openedx.org/t/deploying-open-edx-on-kubernetes-using-helm/8771

oeps/archived/oep-0005/decisions/0004-data-dump.rst

@@ -9,9 +9,9 @@ Accepted
 Context
 *******
 
-One of the goals for DD is to minimize start time/setup time. Setting up the database is one of the major bottlennecks.
+One of the goals for DD is to minimize start time/setup time. Setting up the database is one of the major bottlenecks.
 
-Since this is the begining of DD, the methods of providing necessary data to a general service's DD has not been established. A generalized solution has been proposed in `OEP-37`_, but it does not yet exist.
+Since this is the beginning of DD, the methods of providing necessary data to a general service's DD has not been established. A generalized solution has been proposed in `OEP-37`_, but it does not yet exist.
 
 .. _OEP-37: https://github.com/openedx/open-edx-proposals/pull/118
 

oeps/archived/oep-0005/decisions/0005-centralized-devstack.rst

@@ -10,7 +10,7 @@ Accepted
 Context
 *******
 
-In `decision 0002`_ we argued for replacing `Devstack`_ with Decentralized Devstack, a framework for devstack where each IDA would have and own its own devstack. To test out the new framework, a prototype was created for enterprise-catalog. Our initial spike showed that the reduction in capabality that resulted from moving to this approach was too large for the gains it provided. We discoveredthat developers expected to be able to make modifications across multiple IDAs during development, which did not lend itself to the distributed devstack model.
+In `decision 0002`_ we argued for replacing `Devstack`_ with Decentralized Devstack, a framework for devstack where each IDA would have and own its own devstack. To test out the new framework, a prototype was created for enterprise-catalog. Our initial spike showed that the reduction in capability that resulted from moving to this approach was too large for the gains it provided. We discovered that developers expected to be able to make modifications across multiple IDAs during development, which did not lend itself to the distributed devstack model.
 
 Decision
 ********
@@ -21,7 +21,7 @@ We will continue to maintain a centralized devstack repo.
 Consequences
 ************
 
-All files/changes related to implementation of Decentralized Devstack will be removed, and the decisions hilighted in decisions 0001 and 0002 are now reversed.
+All files/changes related to implementation of Decentralized Devstack will be removed, and the decisions highlighted in decisions 0001 and 0002 are now reversed.
 
 .. _Devstack: https://github.com/openedx/devstack
 .. _decision 0002: https://open-edx-proposals.readthedocs.io/en/latest/oep-0005/decisions/0002-why-decentralized-devstack.html

oeps/archived/oep-0011-bp-FED-technology.rst

@@ -39,7 +39,7 @@ Motivation
 
 The rapid pace of development in front end tooling has created opportunities
 to greatly improve the quality of the Open edX user and developer experience.
-After an assesment of industry best practices, the edX Front End Working Group
+After an assessment of industry best practices, the edX Front End Working Group
 (FedX) has made a number of technology recommendations for libraries, frameworks
 and tooling to modernize the edX front end.
 
@@ -82,7 +82,7 @@ Technology Selection
    New tests must not use Enzyme, and any repositories planning to move to React 18 or newer need to
    replace Enzyme.
 
-#. **Target the latest standardised JavaScript version (ECMA-262)**
+#. **Target the latest standardized JavaScript version (ECMA-262)**
 
    **Rationale**: edX JavaScript should be written consistent with the latest
    ECMA-262 specification in order to ensure future support, the largest
@@ -173,7 +173,7 @@ Technology Selection
 #. **API calls should be made with the edX Frontend Auth Client or Axios**
 
    **Rationale**: The `edX Frontend Auth Client`_ simplifies the process of
-   talking to edX APIs by using Axios inteceptors and handling JWT Cookie
+   talking to edX APIs by using Axios interceptors and handling JWT Cookie
    authentication. It also provides React components to handle private routes
    and should be used when possible. When making calls to non-edX APIs
    Axios should be used to provide a consistent API.
@@ -214,7 +214,7 @@ Decisions
 
 .. note::
 
-   The decesions from this OEP have been moved to :doc:`/best-practices/oep-0067-bp-tools-and-technology`.
+   The decisions from this OEP have been moved to :doc:`/best-practices/oep-0067-bp-tools-and-technology`.
 
 Change History
 **************

oeps/best-practices/oep-0017-bp-feature-toggles.rst

@@ -604,7 +604,7 @@ Existing feature toggles that don't use edx-toggles_ will need to gradually migr
 Non-Django Applications
 =======================
 
-edX applications that are not written in Django (for examply Ruby on Rails or Drupal applications) are currently considered technical debt. There is expectation they will eventually be rewritten or migrated. If in the meantime they need to use feature toggles, they cannot use Django-based edx-toggles_ and should therefore have their own application-specific feature toggle best practices document that applies to their own application.
+edX applications that are not written in Django (for example Ruby on Rails or Drupal applications) are currently considered technical debt. There is expectation they will eventually be rewritten or migrated. If in the meantime they need to use feature toggles, they cannot use Django-based edx-toggles_ and should therefore have their own application-specific feature toggle best practices document that applies to their own application.
 
 Reference Implementation
 ************************
@@ -625,7 +625,7 @@ Here are a few examples of usages of the toggle classes:
 
 Updated examples of feature toggle reporting:
 
-* Sample `readthedocs documention for edx-platform feature toggles`_.
+* Sample `readthedocs documentation for edx-platform feature toggles`_.
 * Based on `annotated toggles in the edx-platform codebase`_.
 
 Updated documentation on feature toggles and reporting:
@@ -634,7 +634,7 @@ Updated documentation on feature toggles and reporting:
 * See `how to document feature toggles`_.
 * See `how to enable feature toggle reports for an IDA`_.
 
-.. _readthedocs documention for edx-platform feature toggles: https://edx.readthedocs.io/projects/edx-platform-technical/en/latest/featuretoggles.html
+.. _readthedocs documentation for edx-platform feature toggles: https://edx.readthedocs.io/projects/edx-platform-technical/en/latest/featuretoggles.html
 .. _annotated toggles in the edx-platform codebase: https://github.com/openedx/edx-platform/search?q=toggle_name
 .. _how to document feature toggles: https://edx.readthedocs.io/projects/edx-toggles/en/latest/how_to/documenting_new_feature_toggles.html
 .. _grading enhancements: https://github.com/openedx/edx-platform/pull/16082

oeps/best-practices/oep-0022-bp-django-caches.rst

@@ -39,7 +39,7 @@ variety of issues were uncovered while working on caching fixes and
 improvements within one of our services.
 
 1. There is a common caching bug while using Django caches where someone
-   caches a value that is Falsey (e.g., None or []) and it is mistakenly
+   caches a value that is Falsy (e.g., None or []) and it is mistakenly
    treated as a cache miss.
 
 2. In Django we commonly use the Memcached back-end. There are various
@@ -77,7 +77,7 @@ The following is a common defect when caching using Django caches::
     cached_value = cache.get(key)
     if not cached_value:
         # calculate value, set in cache, and return
-        # if the calculated value is Falsey (e.g., None or []), it will
+        # if the calculated value is Falsy (e.g., None or []), it will
         # be treated as a cache miss above.
     return cached_value
 
@@ -88,7 +88,7 @@ The simplest fix for this defect is::
     cached_value = cache.get(key, _CACHE_MISS)
     if cached_value is _CACHE_MISS:
         # calculate value, set in cache, and return
-        # if the calculated value is Falsey (e.g., None or []), it will
+        # if the calculated value is Falsy (e.g., None or []), it will
         # no longer be treated as a cache miss above.
     return cached_value
 

oeps/best-practices/oep-0037-bp-test-data.rst

@@ -108,7 +108,7 @@ If there is corresponding dev data that needs to be loaded into another IDA(i.e,
 
 To keep data loading modular, the dev data specification for each IDA should live in its own yaml file.
 
-Each ``load_dev_data`` management command should take the specification from the yaml file and call on the data generation fuctions that correspond to keys in yaml file.
+Each ``load_dev_data`` management command should take the specification from the yaml file and call on the data generation functions that correspond to keys in yaml file.
 
 Each data loading function should be executed during the respective IDA's test suite, in order to ensure that it stays functional across schema and code changes.  This also makes it clear what change triggered failure to load the data, making it much faster to make the appropriate fixes.
 
@@ -119,7 +119,7 @@ Data Files
 
 Dev data for an individual IDA will be specified in a YAML file.  The path or URL of this file is passed to the ``load_dev_data`` management command, which uses the information in it to call the appropriate data generation function to create database records for a particular service as shown above.
 
-These data files should be as minimal as possible, containing just enough information for a data loading function familiar with this format to generate appropriate records using factory classes to fill in reasonable defaults for anything not explicitly specified. This is to increase robustness to code changes and to keep the maintanance cost of these files as low as possible.
+These data files should be as minimal as possible, containing just enough information for a data loading function familiar with this format to generate appropriate records using factory classes to fill in reasonable defaults for anything not explicitly specified. This is to increase robustness to code changes and to keep the maintenance cost of these files as low as possible.
 
 Such a file might look like this: