chore: trailing whitespace removed

README.rst

@@ -43,8 +43,6 @@ all proposed changes and additions on `pull requests`_.
 .. _ReStructured Text (RST): https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html
 .. _pull requests: https://docs.openedx.org/en/latest/developers/quickstarts/first_openedx_pr.html
 
-
-
 Testing Locally
 ***************
 
@@ -56,7 +54,6 @@ Next run the following commands::
 
   pip install sphinx  # it may fail for non-obvious reasons without this
   make requirements
-
   make html
 
 Common Warnings

oeps/best-practices/oep-0049-django-app-patterns.rst

@@ -204,7 +204,7 @@ Example
   from enum import Enum
 
   from attrs import field, frozen, validators
-  
+
   class ProgramStatus(Enum):
       ACTIVE = "active"
       RETIRED = "retired"

oeps/best-practices/oep-0067-bp-tools-and-technology.rst

@@ -68,7 +68,7 @@ This technology is not specific to frontend or backend code.
 
    **Rationale**: It is important to measure the amount of code covered by our
    automated test suites. By striving for a high level of test coverage, we can
-   reduce the number of bugs that can only be found via manual testing, 
+   reduce the number of bugs that can only be found via manual testing,
    and by using codecov to run coverage in CI,
    contributors are automatically reminded to include tests for any new code.
 
@@ -84,12 +84,12 @@ This technology is not specific to frontend or backend code.
 Frontend Technology Selection
 =============================
 
-.. note:: 
+.. note::
 
    The phrase “frontend” is used to mean any part of the platform that is shown to
    users. This encompasses views rendered in Python on the server, interactive
    interfaces written using JavaScript, and CSS styling.
-   
+
 .. _Use React:
 
 #. **Use React**
@@ -250,7 +250,7 @@ Frontend Technology Selection
 
    **Rationale**: It is important for users of the Open edX platform that we deliver
    reasonably sized JavaScript bundles. This provides faster load times to all users,
-   and is vital for users with low bandwidth and/or metered connections. To ensure we 
+   and is vital for users with low bandwidth and/or metered connections. To ensure we
    don't unintentionally increase the size of our JavaScript bundles, we utilize BundleWatch
    for automated bundle size monitoring.
 

oeps/best-practices/oep-0067/decisions/frontend/0006-codecov.rst

@@ -27,6 +27,6 @@ Rejected Alternatives
 Coveralls
 =========
 
-Coveralls has been historically used for tracking coverage but the service has become less reliable over time and the larger python has moved away from it. 
+Coveralls has been historically used for tracking coverage but the service has become less reliable over time and the larger python has moved away from it.
 
 .. _Codecov: https://about.codecov.io/

oeps/best-practices/oep-0067/decisions/frontend/0007-bundle-size.rst

@@ -10,11 +10,11 @@ Context
 *******
 
 It is important for users of the Open edX platform that we deliver reasonably sized JavaScript bundles. This provides
-faster load times to all users, and is vital for users with low bandwidth and/or metered connections.  
+faster load times to all users, and is vital for users with low bandwidth and/or metered connections.
 
 It is currently possible to manually monitor bundle size information by utilizing webpack configurations provided by
 frontend-build, but this functionality is not very discoverable. Given the "hidden" nature of this functionality, it is
-very possible for changes that increase bundle size to be missed in the PR review process. 
+very possible for changes that increase bundle size to be missed in the PR review process.
 
 The increased visibility provided by automated bundle size monitoring will ensure we don't unintentionally increase
 the size of our JavaScript bundles, as well as encourage maintainers to adopt best practices such as `code splitting`_.
@@ -28,7 +28,7 @@ decide if this CI check will be blocking or informative on a repo-by-repo basis.
 BundleWatch
 ===========
 
-`BundleWatch`_ is solely focused on ensuring bundle sizes stay under control. It is actively maintained and used by popular projects such as `bootstrap`_. 
+`BundleWatch`_ is solely focused on ensuring bundle sizes stay under control. It is actively maintained and used by popular projects such as `bootstrap`_.
 
 Consequence
 ***********
@@ -41,13 +41,13 @@ Rejected Alternatives
 *********************
 
 1. **Code Checks**
-  
+
    `Code Checks`_ is a pluggable framework for automated code review. It provides more
    than just bundle size monitoring, presenting us with an opportunity to rethink our
    current CI workflows. For example, Code Checks provides test coverage monitoring,
    which would allow us to re-evaluate the choice to use CodeCov as documented in
    :doc:`0006-codecov`.
-   
+
    While this additional functionality is potentially desirable, moving forward with a
    single purpose tool (`BundleWatch`_) provides us the functionality we need with
    minimal changes to our current CI workflows.

oeps/best-practices/oep-0067/decisions/frontend/0008-typescript.rst

@@ -9,8 +9,8 @@ Accepted
 Context
 *******
 
-As documented in :doc:`OEP-0011-0004 <0004-js-ecma>`, the Open edX community has previously 
-:ref:`decided against adopting TypeScript <Reasons for rejecting TypeScript>`. In the time 
+As documented in :doc:`OEP-0011-0004 <0004-js-ecma>`, the Open edX community has previously
+:ref:`decided against adopting TypeScript <Reasons for rejecting TypeScript>`. In the time
 since that decision was made, TypeScript has grown to be quite popular and commonplace for JavaScript developers.
 This has led to more discussion within the community about the `pros and cons of adopting TypeScript`_.
 
@@ -33,7 +33,7 @@ Rejected Alternatives
 *********************
 
 1. **Continue without TypeScript**
-  
+
    It is possible to use other tools to add some of the functionality TypeScript provides
    to JavaScript code. However, considering the main point of opposition to TypeScript adoption
    was keeping a low barrier of entry for frontend developers, this could be counterproductive.
@@ -42,6 +42,6 @@ Rejected Alternatives
 
    It would be possible to convert all JavaScript throughout the Open edX project (or any given
    repository within the project) to TypeScript. It is not clear what the benefit of doing so would
-   be. 
+   be.
 
 .. _pros and cons of adopting TypeScript: https://github.com/openedx/paragon/discussions/1186

oeps/best-practices/oep-0067/decisions/frontend/0009-renovate.rst

@@ -48,9 +48,9 @@ Rejected Alternatives
      for identifying the root cause of a test failure but resulted in a
      pretty high volume of PRs that needed to be reviewed (especially in
      repositories which normally don't need to be updated very often). Renovate has
-     `configuration options to set the frequency of checking for new dependency 
+     `configuration options to set the frequency of checking for new dependency
      releases <https://renovatebot.com/docs/noise-reduction/#scheduling-renovate>`_,
-     and to allow related packages to be `updated in the same pull 
+     and to allow related packages to be `updated in the same pull
      request <https://renovatebot.com/docs/noise-reduction/#package-grouping>`_. This may
      delay notification of security patch releases or make it harder to identify the
      exact cause of a test failure, but also makes it less likely that the PRs will be

oeps/processes/oep-0014-proc-archive-repos.rst

@@ -89,9 +89,9 @@ These steps should be followed for all repos within the Open edX organization (f
   - Move the repository to the openedx-unsupported organization
 
   - Remove references to the repository from the ``openedx-translations`` `repository <https://github.com/openedx/openedx-translations/>`_
-    
+
     - The entry in the ``extract-translation-source-files`` `workflow <https://github.com/openedx/openedx-translations/blob/main/.github/workflows/extract-translation-source-files.yml>`_
-    
+
     - The subdirectory in the ``translations`` `directory <https://github.com/openedx/openedx-translations/tree/main/translations>`_
 
   - Create an ``axim-engineering`` `request <https://github.com/openedx/axim-engineering/issues/new/choose>`_ to remove the repository resource from the ``openedx-translations`` project on Transifex

oeps/processes/oep-0021-proc-deprecation.rst

@@ -317,7 +317,7 @@ The coordinator is responsible for:
 
 When you are ready to coordinate the ticket, post a comment on the
 GitHub issue saying you're doing so, and mark yourself as the GitHub
-issue's owner.  This can be done even if you don't have write access to 
+issue's owner.  This can be done even if you don't have write access to
 the ticket by making a comment on the ticket that says ``assign me``.
 
 .. note::

oeps/processes/oep-0055/decisions/0001-use-backstage-to-support-maintainers.rst

@@ -123,7 +123,7 @@ References
         # names that might be interested in changes to the architecture of this
         # component.
         openedx.org/arch-interest-groups: "feanil"
-        # (Optional) We use the below annotation to indicate whether or not this 
+        # (Optional) We use the below annotation to indicate whether or not this
         # repository should be tagged for openedx releases and which branch is tagged.
         openedx.org/release: "main"
     spec:

oeps/processes/oep-0057-proc-core-product.rst

@@ -86,7 +86,7 @@ Product Narrative
 The *Product Narrative* is defined as the high-level vision statement for the
 Open edX project. It succinctly articulates the value proposition and impact of
 the project, the features which differentiate it, and the values and
-characteristics that position it as a market-leading solution. 
+characteristics that position it as a market-leading solution.
 
 Ongoing work to define the Product Narrative and subsequent deliverables can be
 tracked on the `Product Narrative wiki space`_.
@@ -114,7 +114,7 @@ questions such as:
   Product, and why?
 
 * What is the spectrum of alternatives if a developed feature doesn't align with
-  the Core Product? 
+  the Core Product?
 
 Ongoing work to define the Core Product and subsequent deliverables can be
 tracked on the `Core Product Offering wiki space`_.
@@ -245,7 +245,7 @@ the highest impact parts of the project, as determined by a broad cross-section
 of the community itself. It will be clearer to the community which portions of
 the release they can expect support on, and which portions will have little to
 no support. Those components residing outside of the Core Product's Bundled
-Extensions will not be a priority of the project's product strategy. 
+Extensions will not be a priority of the project's product strategy.
 
 The Core Product will be the focus of the project's product strategy; the
 project's various working groups are expected to prioritize support of the Core
@@ -273,7 +273,7 @@ A clearly defined Core Product will assist product managers conducting market
 research to more easily identify feature gaps and parity analyses. They can ask
 questions such as: Do the highest impact features of the project adequately meet
 user needs? Where are they weak? How can we best invest to address those
-weaknesses? 
+weaknesses?
 
 Marketing and Growth Efforts
 ============================
@@ -297,7 +297,7 @@ Notes
     There is desire in the Open edX community to refactor some or all of these
     features to be Bundled Extensions, which would reduce the size of the Kernel
     and bring it closer to our conceptions of an Ideal Kernel.
-    
+
     The diagram of the Product Offerings and what they contain in the text
     represents a simplified version of what the Product Offerings are, and how
     they interact. A more full version of this visual can be seen below
@@ -341,7 +341,7 @@ Notes
 
 .. _Richie: https://richie.education/
 
-.. _FUN MOOC: https://www.fun-mooc.fr/en/ 
+.. _FUN MOOC: https://www.fun-mooc.fr/en/
 
 .. _OEP-10: https://open-edx-proposals.readthedocs.io/en/latest/processes/oep-0010-proc-openedx-releases.html
 

oeps/processes/oep-0063-proc-toc-resolution-request.rst

@@ -32,9 +32,9 @@ Abstract
 
 The Technical Oversight Committee (TOC) is meant to be a resource for the Open edX project. Thus it is important that there are clear lines of communication between the TOC and Open edX community. The purpose of this OEP is to establish and define those lines of communication.
 
-The TOC aims to empower the project's contributors to make decisions. The person closest to the work will often know best, and empowered contributors face less friction. 
+The TOC aims to empower the project's contributors to make decisions. The person closest to the work will often know best, and empowered contributors face less friction.
 
-However, some of the topics can be complex, such as making changes which will have long-lasting repercussions or when there is no consensus on a topic within the community. In this OEP, the TOC defines a process for community members to bring up topics to the committee's attention, and request its support on the matter. The TOC responds through the adoption of resolutions, for example intervening on the discussion or taking a decision about a proposal. 
+However, some of the topics can be complex, such as making changes which will have long-lasting repercussions or when there is no consensus on a topic within the community. In this OEP, the TOC defines a process for community members to bring up topics to the committee's attention, and request its support on the matter. The TOC responds through the adoption of resolutions, for example intervening on the discussion or taking a decision about a proposal.
 
 Motivation
 **********
@@ -47,13 +47,13 @@ Guidelines
 From the `TOC meeting notes <https://discuss.openedx.org/t/2023-04-11-toc-meeting-summary/10019#governance-norms-5>`_:
 
 *The TOC should not operate “in the weeds.” We don’t have the time to be involved day-to-day technical decisions, and those closest to the work will make the best decisions. The TOC should not act as a “stage gate.” We should not create friction for contributors unnecessarily, but should:*
-   
+
 - *Guide the project toward shared goals*
 - *Help refine and improve plans and designs*
 - *Prevent the project from making bad decisions that are hard to reverse.*
-   
+
 *The TOC should weigh in:*
-   
+
 - *on “one-way-doors,” decisions that are hard to reverse, where choices are mutually exclusive*
 - *when the community is having difficulty reaching consensus*
 - *when an important decision is being deferred and not making a call is causing friction*
@@ -72,8 +72,8 @@ Step-by-step - How to Submit a Resolution Request
 - After public review, post a formal Resolution Request to the TOC, by opening a `github ticket <https://github.com/openedx/wg-coordination/issues/new>`_. Mention the `TOC chair <https://openedx.atlassian.net/wiki/spaces/COMM/pages/3575939113/Technical+Oversight+Committee+TOC#Details>`_ in the request to make sure they get notified. See the format below.
 - Notify the participants of the public discussions that you have created the TOC Resolution Request, by posting a link to it in the discussion threads.
 - Core contributors and/or TOC members supporting the Resolution Request reply in the thread to say so.
-- If the requirements are met, the TOC will schedule the topic for a future meeting. 
-- If the Resolution Request contains a suggested decision, the TOC can choose to accept the suggested decision, with or without changes, or to refuse it. 
+- If the requirements are met, the TOC will schedule the topic for a future meeting.
+- If the Resolution Request contains a suggested decision, the TOC can choose to accept the suggested decision, with or without changes, or to refuse it.
 - The adopted Resolution is communicated as a reply to the github ticket, with a comment to explain it.
 
 Resolution Request - Github Ticket Template
@@ -82,17 +82,17 @@ Resolution Request - Github Ticket Template
 .. code-block:: none
 
    Subj: TOC Resolution Request - [Title]
-   
+
    ---------------------
-   
+
    ## [Title]
-   
-   ## Summary 
+
+   ## Summary
    [Prior discussion of this topic (with links)]
-   
+
    ## Rationale for involving the TOC
    [Why this topic would benefit from the TOC involvement]
-   
+
    ## Resolution requested
    [The precise description of the request to the TOC, optionally including a specific decision to take if applicable. Note that the TOC doesn't have to take exactly that decision, it can modify it, or refuse it.]