From 0c4e5fcfb0595592ba8aad9fb2aaaf6b6c16a4e1 Mon Sep 17 00:00:00 2001 From: Emad Rad Date: Mon, 6 Nov 2023 15:35:08 +0330 Subject: [PATCH] chore: fixed typos. --- .../oep-0003-arch-async-tasks.rst | 2 +- .../oep-0006-arch-context-xblock-fields.rst | 4 ++-- .../oep-0026-arch-realtime-events.rst | 4 ++-- .../oep-0026/caliper-realtime-events.rst | 2 +- .../oep-0031-arch-i18n.rst | 2 +- ...oep-0032-arch-unique-identifier-for-users.rst | 2 +- ...ep-0041-arch-async-server-event-messaging.rst | 6 +++--- ...utor-as-replacement-for-edx-configuration.rst | 2 +- .../0002-helm-for-multi-instance-k8s.rst | 4 ++-- .../oep-0005/decisions/0004-data-dump.rst | 4 ++-- .../decisions/0005-centralized-devstack.rst | 4 ++-- oeps/archived/oep-0011-bp-FED-technology.rst | 8 ++++---- .../oep-0017-bp-feature-toggles.rst | 6 +++--- .../best-practices/oep-0022-bp-django-caches.rst | 6 +++--- oeps/best-practices/oep-0037-bp-test-data.rst | 4 ++-- .../decisions/0001-yaml-centralization.rst | 4 ++-- .../decisions/0003-data-creation-functions.rst | 2 +- .../best-practices/oep-0066-bp-authorization.rst | 8 ++++---- .../oep-0066/Open_edX_Auth_Overview_Table.rst | 2 +- ...en_edX_Authorization_Explicit_Roles_Table.rst | 6 +++--- .../oep-0067-bp-tools-and-technology.rst | 4 ++-- .../oep-0067/decisions/frontend/0001-react.rst | 2 +- .../oep-0067/decisions/frontend/0004-js-ecma.rst | 2 +- oeps/processes/oep-0001.rst | 6 +++--- oeps/processes/oep-0054-core-contributors.rst | 8 ++++---- .../oep-0055-proc-project-maintainers.rst | 16 ++++++++-------- .../0002-maintainership-transfer-process.rst | 2 +- .../decisions/0003-readme-specification.rst | 2 +- ...-0056-proc-architectural-advisory-process.rst | 4 ++-- oeps/processes/oep-0060-proc-sec-group.rst | 2 +- 30 files changed, 65 insertions(+), 65 deletions(-) diff --git a/oeps/architectural-decisions/oep-0003-arch-async-tasks.rst b/oeps/architectural-decisions/oep-0003-arch-async-tasks.rst index 5095035c6..f30fcb601 100644 --- a/oeps/architectural-decisions/oep-0003-arch-async-tasks.rst +++ b/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. diff --git a/oeps/architectural-decisions/oep-0006-arch-context-xblock-fields.rst b/oeps/architectural-decisions/oep-0006-arch-context-xblock-fields.rst index 177ea5f83..61712b1e7 100644 --- a/oeps/architectural-decisions/oep-0006-arch-context-xblock-fields.rst +++ b/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`_. diff --git a/oeps/architectural-decisions/oep-0026-arch-realtime-events.rst b/oeps/architectural-decisions/oep-0026-arch-realtime-events.rst index aa66beed2..824a0fa45 100644 --- a/oeps/architectural-decisions/oep-0026-arch-realtime-events.rst +++ b/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 diff --git a/oeps/architectural-decisions/oep-0026/caliper-realtime-events.rst b/oeps/architectural-decisions/oep-0026/caliper-realtime-events.rst index d72033be3..5565b29bd 100644 --- a/oeps/architectural-decisions/oep-0026/caliper-realtime-events.rst +++ b/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 ************************************ diff --git a/oeps/architectural-decisions/oep-0031-arch-i18n.rst b/oeps/architectural-decisions/oep-0031-arch-i18n.rst index 51d1af1e5..abd7ff873 100644 --- a/oeps/architectural-decisions/oep-0031-arch-i18n.rst +++ b/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 diff --git a/oeps/architectural-decisions/oep-0032-arch-unique-identifier-for-users.rst b/oeps/architectural-decisions/oep-0032-arch-unique-identifier-for-users.rst index 29744f05a..b09b8c3fd 100644 --- a/oeps/architectural-decisions/oep-0032-arch-unique-identifier-for-users.rst +++ b/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. diff --git a/oeps/architectural-decisions/oep-0041-arch-async-server-event-messaging.rst b/oeps/architectural-decisions/oep-0041-arch-async-server-event-messaging.rst index 6906a2781..76ccd66f0 100644 --- a/oeps/architectural-decisions/oep-0041-arch-async-server-event-messaging.rst +++ b/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 `_ 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. diff --git a/oeps/architectural-decisions/oep-0045/decisions/0001-tutor-as-replacement-for-edx-configuration.rst b/oeps/architectural-decisions/oep-0045/decisions/0001-tutor-as-replacement-for-edx-configuration.rst index 3648945b3..add9c4aed 100644 --- a/oeps/architectural-decisions/oep-0045/decisions/0001-tutor-as-replacement-for-edx-configuration.rst +++ b/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 diff --git a/oeps/architectural-decisions/oep-0045/decisions/0002-helm-for-multi-instance-k8s.rst b/oeps/architectural-decisions/oep-0045/decisions/0002-helm-for-multi-instance-k8s.rst index 0bcf2acc8..634197d57 100644 --- a/oeps/architectural-decisions/oep-0045/decisions/0002-helm-for-multi-instance-k8s.rst +++ b/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 diff --git a/oeps/archived/oep-0005/decisions/0004-data-dump.rst b/oeps/archived/oep-0005/decisions/0004-data-dump.rst index 2daf88d7f..b490ae4a3 100644 --- a/oeps/archived/oep-0005/decisions/0004-data-dump.rst +++ b/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 diff --git a/oeps/archived/oep-0005/decisions/0005-centralized-devstack.rst b/oeps/archived/oep-0005/decisions/0005-centralized-devstack.rst index 44ffb61c3..570ae5070 100644 --- a/oeps/archived/oep-0005/decisions/0005-centralized-devstack.rst +++ b/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 diff --git a/oeps/archived/oep-0011-bp-FED-technology.rst b/oeps/archived/oep-0011-bp-FED-technology.rst index f9adfc339..ad3c10f24 100644 --- a/oeps/archived/oep-0011-bp-FED-technology.rst +++ b/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 ************** diff --git a/oeps/best-practices/oep-0017-bp-feature-toggles.rst b/oeps/best-practices/oep-0017-bp-feature-toggles.rst index 01ed78139..9469b8252 100644 --- a/oeps/best-practices/oep-0017-bp-feature-toggles.rst +++ b/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 diff --git a/oeps/best-practices/oep-0022-bp-django-caches.rst b/oeps/best-practices/oep-0022-bp-django-caches.rst index 3a8b504c2..a6677aec6 100644 --- a/oeps/best-practices/oep-0022-bp-django-caches.rst +++ b/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 diff --git a/oeps/best-practices/oep-0037-bp-test-data.rst b/oeps/best-practices/oep-0037-bp-test-data.rst index a4e31d3cd..314d06212 100644 --- a/oeps/best-practices/oep-0037-bp-test-data.rst +++ b/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: diff --git a/oeps/best-practices/oep-0037/decisions/0001-yaml-centralization.rst b/oeps/best-practices/oep-0037/decisions/0001-yaml-centralization.rst index 027d3f5e9..3b0ada4e8 100644 --- a/oeps/best-practices/oep-0037/decisions/0001-yaml-centralization.rst +++ b/oeps/best-practices/oep-0037/decisions/0001-yaml-centralization.rst @@ -11,13 +11,13 @@ Context Devstack currently has no standard way of creating dev data. Over time, developers have figured out their own ways to create data for local development. Recently, `OEP-37`_ was proposed, which suggests a standardized method for creating dev data. We decided the proposal was good enough to warrant a prototype and during the prototyping phase, we ran into the question of how much of this method we want to centralize into devstack, vs keep things decentralized by keeping as much as is possible in each IDAs. -Specifically, this ADR pertains to question of where to put yaml files specifiying what data to load into the devstack development environment. As it is implemented, each IDA will have its own yaml files which lay out what data to create for that IDA. +Specifically, this ADR pertains to question of where to put yaml files specifying what data to load into the devstack development environment. As it is implemented, each IDA will have its own yaml files which lay out what data to create for that IDA. Decision ******** -Since this method is meant to be used in devstack to orchestrate dev data across multiple IDAs, we decided to put all of the data yaml files into the devstack repo. This decision is especially relavant for yaml files specifiying what data to create during provisioning and for very specific common workflows. The hope is that developers will only have to modify yaml files in devstack repo to create more custom data. +Since this method is meant to be used in devstack to orchestrate dev data across multiple IDAs, we decided to put all of the data yaml files into the devstack repo. This decision is especially relevant for yaml files specifying what data to create during provisioning and for very specific common workflows. The hope is that developers will only have to modify yaml files in devstack repo to create more custom data. Clarification, this decision does not restrict yaml files existing in each individual IDA's repo. diff --git a/oeps/best-practices/oep-0037/decisions/0003-data-creation-functions.rst b/oeps/best-practices/oep-0037/decisions/0003-data-creation-functions.rst index 7df1fc64f..f082214e5 100644 --- a/oeps/best-practices/oep-0037/decisions/0003-data-creation-functions.rst +++ b/oeps/best-practices/oep-0037/decisions/0003-data-creation-functions.rst @@ -23,7 +23,7 @@ Consequences - Dev data generation is centralized to `load_dev_data` management command in each IDA - The file will grow larger as new data is supported -- `load_dev_data` management command will be modified everytime new data is supported +- `load_dev_data` management command will be modified every time new data is supported diff --git a/oeps/best-practices/oep-0066-bp-authorization.rst b/oeps/best-practices/oep-0066-bp-authorization.rst index 48fac5753..888e14f86 100644 --- a/oeps/best-practices/oep-0066-bp-authorization.rst +++ b/oeps/best-practices/oep-0066-bp-authorization.rst @@ -423,7 +423,7 @@ content_libraries_contentlibrarypermission Permission is granted on a Feature, in this case Content Library. -Permission is assigned in the CMS exclusively for providiing explicit permission to +Permission is assigned in the CMS exclusively for providing explicit permission to view or edit a library in the CMS. It grants access on a library by library basis and is used for v2 of content libraries @@ -452,7 +452,7 @@ If a feature/service utilizes a system-wide role, the feature/service enforces t Example System-wide Role: -* Global Staff - propogated in JWTs as the "administrator" field +* Global Staff - propagated in JWTs as the "administrator" field Example AuthZ User Access Flows ------------------------------- @@ -466,13 +466,13 @@ User 1 is assigned to User Group 1 and User Group 2. Being in User Group 1 grants the user System-wide Role A and System-wide Role B, which in turn each grant a specific permission set or sets for a service. Being in User Group 2 grants access to System-wide Role C -which grants access to a service permisison set. +which grants access to a service permission set. User 2 is assigned to User Group 2. Being in User Group 2 grants access to System-wide Role C which grants access to a service permission set. User 2 is also directly assigned System-wide Role D -which grants access to a different servie permission set. +which grants access to a different service permission set. User 2 is also assigned Service/Feature Role A which grants access to a service permission set. diff --git a/oeps/best-practices/oep-0066/Open_edX_Auth_Overview_Table.rst b/oeps/best-practices/oep-0066/Open_edX_Auth_Overview_Table.rst index 48c61a16c..4334ffbfc 100644 --- a/oeps/best-practices/oep-0066/Open_edX_Auth_Overview_Table.rst +++ b/oeps/best-practices/oep-0066/Open_edX_Auth_Overview_Table.rst @@ -7,7 +7,7 @@ Open edX Auth Overview Table * - Authentication (AuthN) - Authorization (AuthZ) * - Users should receive a JWT Token once authenticated. - - Access is determined using a combination of the explicit and implicit role gratning. Logic may check a combination of the systems (or just one) and may check them in any order. Logic may use && or || depending on the specific Authn and Authz needs. + - Access is determined using a combination of the explicit and implicit role granting. Logic may check a combination of the systems (or just one) and may check them in any order. Logic may use && or || depending on the specific Authn and Authz needs. * - Each Open edX instance may utilize different authentication options. - Roles assigned with edx-rbac are stored on the JWT and retrieved as part of `JWT creation `_ * - diff --git a/oeps/best-practices/oep-0066/Open_edX_Authorization_Explicit_Roles_Table.rst b/oeps/best-practices/oep-0066/Open_edX_Authorization_Explicit_Roles_Table.rst index 178b14c01..697ef39a3 100644 --- a/oeps/best-practices/oep-0066/Open_edX_Authorization_Explicit_Roles_Table.rst +++ b/oeps/best-practices/oep-0066/Open_edX_Authorization_Explicit_Roles_Table.rst @@ -94,7 +94,7 @@ edx Platform - Django Admin Flow * - **System Details** - * Set in the Django Admin Control Panel - * users for the instance with superiser role (highest access level) have access to this functionality + * users for the instance with superuser role (highest access level) have access to this functionality * poor UX, poor discoverability, overly complex and possibly more error prone *Note: Other services have their own Django Admin Panels that grant permissions.* @@ -103,7 +103,7 @@ edx Platform - Django Admin Flow * All tables are in the edx-platform LMS database * auth_permission table with codename, content_type_id, id_name fields * auth_group table with id, name fields - * auth_group_permissions table with group_id, permission, permission_id, _sdc_deteled_at fields + * auth_group_permissions table with group_id, permission, permission_id, _sdc_deleted_at fields * auth_user table with id, email, username, and many other fields * auth_user_groups table with group_id, id, user_id, _sdc_deleted_at fields * auth_user_user_permissions table with id, permission_id, user_id fields @@ -132,7 +132,7 @@ edx-rbac * Each service determines what other roles can explicitly grant access and where implicit access can come from (i.e. a system wide role may have implicit access) * Roles can be assigned for a feature or the service * The edX-rbac spec is designed to be usable by an instance, org, or service - * Role assignments typlically "stored" in the JWT cookie, but roles are stored in the db and therefore can be used from the db. + * Role assignments typically "stored" in the JWT cookie, but roles are stored in the db and therefore can be used from the db. * - **Data Model** - * Each service that uses edX-rbac has its own db tables. diff --git a/oeps/best-practices/oep-0067-bp-tools-and-technology.rst b/oeps/best-practices/oep-0067-bp-tools-and-technology.rst index 76463709a..b2f43eafc 100644 --- a/oeps/best-practices/oep-0067-bp-tools-and-technology.rst +++ b/oeps/best-practices/oep-0067-bp-tools-and-technology.rst @@ -118,7 +118,7 @@ Frontend 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 @@ -209,7 +209,7 @@ Frontend 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. diff --git a/oeps/best-practices/oep-0067/decisions/frontend/0001-react.rst b/oeps/best-practices/oep-0067/decisions/frontend/0001-react.rst index 7ee7f645c..b6a452955 100644 --- a/oeps/best-practices/oep-0067/decisions/frontend/0001-react.rst +++ b/oeps/best-practices/oep-0067/decisions/frontend/0001-react.rst @@ -10,7 +10,7 @@ Context ******* The Open edX community needs a standardized framework for building new UIs that is -widely adopted, flexibile, and feature rich. +widely adopted, flexible, and feature rich. Decision ******** diff --git a/oeps/best-practices/oep-0067/decisions/frontend/0004-js-ecma.rst b/oeps/best-practices/oep-0067/decisions/frontend/0004-js-ecma.rst index 5658e4466..f23f8e15b 100644 --- a/oeps/best-practices/oep-0067/decisions/frontend/0004-js-ecma.rst +++ b/oeps/best-practices/oep-0067/decisions/frontend/0004-js-ecma.rst @@ -1,4 +1,4 @@ -Target the latest standardised JavaScript version +Target the latest standardized JavaScript version ################################################# Status diff --git a/oeps/processes/oep-0001.rst b/oeps/processes/oep-0001.rst index c5c630cba..7d38349cf 100644 --- a/oeps/processes/oep-0001.rst +++ b/oeps/processes/oep-0001.rst @@ -51,7 +51,7 @@ Overview ******** * An Open edX Proposal specifies a best practice, architectural decision, or - community process that the Open edX communty has agreed should be adopted by + community process that the Open edX community has agreed should be adopted by the project. * OEPs are not used to dictate small decisions made in every day feature work. See `OEP-19 `_ @@ -115,7 +115,7 @@ An Author of an OEP cannot concurrently be the Arbiter of that OEP. In brief, the Arbiter... -* Is knowledgable about the contents of the proposal, while also being able to +* Is knowledgeable about the contents of the proposal, while also being able to fairly hear all sides of a discussion. * Helps the Authors move the OEP through the `OEP Workflow`_, namely: @@ -518,7 +518,7 @@ described below. All other rows are required. .. _Review Period: -* The **Review Period** header specifes the target dates for reviewing the OEP, as +* The **Review Period** header specifies the target dates for reviewing the OEP, as agreed by the Authors and Arbiter. The recommended duration of the review is 2 weeks. However, if the review exposes areas of the proposal that need further discussion and fleshing out, then the Arbiter may choose to extend diff --git a/oeps/processes/oep-0054-core-contributors.rst b/oeps/processes/oep-0054-core-contributors.rst index f8eeb88d4..b0fed40a2 100644 --- a/oeps/processes/oep-0054-core-contributors.rst +++ b/oeps/processes/oep-0054-core-contributors.rst @@ -98,7 +98,7 @@ Core Contributor conduct, particularly whether they follow the "3 Cs" removal from the Program. `Contact the Program Administrators`_ as needed. The Axim administrator(s) are the point people for making sure that needed -agreements are signed. Formost, this is a Program Agreement between the CC and +agreements are signed. Foremost, this is a Program Agreement between the CC and Axim (sent to you by a Program Administrator). Additionally, if the CC commits code to a GitHub repo, a CLA is needed (which should have been signed when you made your first PR). Finally, for new companies or organizations joining the @@ -387,19 +387,19 @@ Change History 2022-02-28 ========== -* Elaborate on CC's responsibilites to fulfill their commitment +* Elaborate on CC's responsibilities to fulfill their commitment * `Pull request #304 `_ 2022-02-16 ========== -* Added clarifiations around the voting process for new CC members. +* Added clarifications around the voting process for new CC members. * `Pull request #293 `_ 2022-02-11 ========== -* Specify how to expand responsibilites for roles with fine-grained permissions +* Specify how to expand responsibilities for roles with fine-grained permissions (such as code committers) * `Pull request #296 `_ diff --git a/oeps/processes/oep-0055-proc-project-maintainers.rst b/oeps/processes/oep-0055-proc-project-maintainers.rst index 94dccdaa1..800f5619f 100644 --- a/oeps/processes/oep-0055-proc-project-maintainers.rst +++ b/oeps/processes/oep-0055-proc-project-maintainers.rst @@ -204,7 +204,7 @@ See `Jobs of the Maintainer`_ for more details on these requirements. It is acceptable for a component to be maintained by a team or group as long as that arrangement does not reduce the reachability of at least one maintainer or -reduce accountability for the above responsibilites. The maintaining team must +reduce accountability for the above responsibilities. The maintaining team must have ways of direct contact, such as an email address and a GitHub team, that anyone can use to get ahold of someone - it is completely acceptable for the team to figure out arrangements for list monitoring, such as an "on-call" @@ -307,7 +307,7 @@ any member of the community including the nominee themselves. If there is no objection from existing maintainers, the role will be conferred. -If consensus cannot be reached lazily [#lazy_concensus]_, a vote of existing maintainers +If consensus cannot be reached lazily [#lazy_consensus]_, a vote of existing maintainers will be taken. Maintainers can approve a nomination with the approval of at least three quarters of the members. @@ -333,7 +333,7 @@ Trigger events for removing a maintainer would be: despite feedback In the case that a maintainer has violated the `Code of Conduct`_, the -Goverance Team, specified in the Code of Conduct, will decide what the +Governance Team, specified in the Code of Conduct, will decide what the repercussions of the violation will be, including whether the violator can continue in the role of maintainer. It should be noted that maintainers are expected to be exemplars and, as such, will be held to @@ -481,7 +481,7 @@ Notes maintainer great, what are the best-practices maintainers should follow, how do we ensure maintainer don't burn out, how do we ensure critical parts of the software supply chain, like - OpenSSL are maintained, etc. I have included some revelant + OpenSSL are maintained, etc. I have included some relevant materials in the **Source Material** section. .. [#ops] Needless to say, there must be feedback loops between @@ -498,13 +498,13 @@ Notes (2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE))(`Alternative Link `_). -.. [#lazy_concensus] Lazy concensus is a process by which decisions +.. [#lazy_consensus] Lazy consensus is a process by which decisions are approved unless there are objections. It is sometimes - described as the "silence is concent" method. Lazy concensus - reduces ceremony and overhead and thus increases spead. It is + described as the "silence is concent" method. Lazy consensus + reduces ceremony and overhead and thus increases speed. It is essential, however, that decisions to be made are published. There should be a review period that is commensurate with the - gravity of the decision at hand. Lazy concensus is used by + gravity of the decision at hand. Lazy consensus is used by other open-source projects and foundations including the `Apache foundation `_ diff --git a/oeps/processes/oep-0055/decisions/0002-maintainership-transfer-process.rst b/oeps/processes/oep-0055/decisions/0002-maintainership-transfer-process.rst index 3b5789ccc..3cd4d02dd 100644 --- a/oeps/processes/oep-0055/decisions/0002-maintainership-transfer-process.rst +++ b/oeps/processes/oep-0055/decisions/0002-maintainership-transfer-process.rst @@ -90,7 +90,7 @@ If a new maintainer is found, initiate the transfer process. #. Add the new maintainer(s) to the relevant maintainers GitHub group. ``-maintainers`` -#. (Optional but recommended) Meet with the new maintainers and review what is being transfered and any relevant knowledge that needs to be transferred. +#. (Optional but recommended) Meet with the new maintainers and review what is being transferred and any relevant knowledge that needs to be transferred. #. Ask the new maintainers to remove you from the maintainers group. diff --git a/oeps/processes/oep-0055/decisions/0003-readme-specification.rst b/oeps/processes/oep-0055/decisions/0003-readme-specification.rst index e2196be93..17ba33caa 100644 --- a/oeps/processes/oep-0055/decisions/0003-readme-specification.rst +++ b/oeps/processes/oep-0055/decisions/0003-readme-specification.rst @@ -10,7 +10,7 @@ Context ******* `OEP-55`_ states that one of the jobs of a maintainer is to maintain an -up-to-date and useful readme. While it laid out some possibilites about what +up-to-date and useful readme. While it laid out some possibilities about what should go into a README, it did not go into much detail. `OEP-19`_ also suggests that README files should exist but does not provide a diff --git a/oeps/processes/oep-0056-proc-architectural-advisory-process.rst b/oeps/processes/oep-0056-proc-architectural-advisory-process.rst index 08291d11f..90c973509 100644 --- a/oeps/processes/oep-0056-proc-architectural-advisory-process.rst +++ b/oeps/processes/oep-0056-proc-architectural-advisory-process.rst @@ -77,7 +77,7 @@ We will adjust our current architectural decision making process by: - Formalizing and clarifying an **Architectural Advisory Process** in which we conversationally provide input on and promptly review the status of ADRs, as well as review updates to our architectural principles and tech radar, with the goal of enabling more effective, informed decision making. - Improve the discoverability of impacted stakeholders and subject matter experts via a **decision impact checklist**. -- Set decision makers up for success by reducing the barrier to entry for new ADRs. This may include an updated ADR template, PR templates, a short step by step guide, and increasing the visiblity and discoverability of active decisions and documentation on the AAP. +- Set decision makers up for success by reducing the barrier to entry for new ADRs. This may include an updated ADR template, PR templates, a short step by step guide, and increasing the visibility and discoverability of active decisions and documentation on the AAP. - Maintain cross-team and cross-organization alignment by using the Architectural Advisory Process to **vet changes to our architectural principles and tech radar**. Our architectural values and technology choices are both are crucial inputs into the decision making process. Architectural Advisory Process (AAP) @@ -123,7 +123,7 @@ We assert that anyone can make an architectural decision, and that the only cave Encourage approachable decision making ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The process of making a technical decision is not atomic, nor do many parts of it occur while writing a document about the decision. Many decisions are *made* while writing code as we problem solve and navigate the idiosyncracies of the system. The goal of our process should be to find a way of sharing and capturing those decisions where they impact others. In this spirit, we encourage using "low-friction" artifacts - such as GitHub Issues - in those moments where drafting a full ADR document would be prohibitively distracting. An issue is an easy place to gather quick, initial input, and naturally becomes resolved by a GitHub Pull Request - the ADR - which describes the decision in more detail. +The process of making a technical decision is not atomic, nor do many parts of it occur while writing a document about the decision. Many decisions are *made* while writing code as we problem solve and navigate the idiosyncrasies of the system. The goal of our process should be to find a way of sharing and capturing those decisions where they impact others. In this spirit, we encourage using "low-friction" artifacts - such as GitHub Issues - in those moments where drafting a full ADR document would be prohibitively distracting. An issue is an easy place to gather quick, initial input, and naturally becomes resolved by a GitHub Pull Request - the ADR - which describes the decision in more detail. Decisions can have varying impacts and scopes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/oeps/processes/oep-0060-proc-sec-group.rst b/oeps/processes/oep-0060-proc-sec-group.rst index 90e485c58..68803adb4 100644 --- a/oeps/processes/oep-0060-proc-sec-group.rst +++ b/oeps/processes/oep-0060-proc-sec-group.rst @@ -211,7 +211,7 @@ What do I do if I am an operator and someone reports a vulnerability to me? What will happen if a report is accidentally sent to security@openedx.org for the operation of my Open edX instance? -* Please let security@openedx.org know the best email (preferably a group email, like security@company.com) to forward such reports to, along with your Open edX instance name, domain, and separate contact information for an indidual responsible for security at your organization. The Security Working Group will do their best to forward such reports to the correct organization. +* Please let security@openedx.org know the best email (preferably a group email, like security@company.com) to forward such reports to, along with your Open edX instance name, domain, and separate contact information for an individual responsible for security at your organization. The Security Working Group will do their best to forward such reports to the correct organization. How do I receive notification of the release of upcoming security patches?