[DATALAD RUNCMD] run codespell throughout fixing typos automagically

=== Do not change lines below ===
{
 "chain": [],
 "cmd": "codespell -w",
 "exit": 0,
 "extra_inputs": [],
 "inputs": [],
 "outputs": [],
 "pwd": "."
}
^^^ Do not change lines above ^^^

Author: yarikoptic

.github/ISSUE_TEMPLATE/feature.md

@@ -1,6 +1,6 @@
 ---
 name: Feature/improvement proposal
-about: Propose a new feauture or improvement for Read the Docs
+about: Propose a new feature or improvement for Read the Docs
 ---
 
 ## What's the problem this feature will solve?

.github/workflows/pip-tools.yaml

@@ -1,5 +1,5 @@
 # Action to run pip-compile weekly and create a Pull Request with the changes.
-# Althought GitHub says that pip-compile is supported by dependabot, we couldn't make it work together.
+# Although GitHub says that pip-compile is supported by dependabot, we couldn't make it work together.
 # That's why this action exists.
 # If we ever find the proper configuration for dependabot+pip-compile,
 # we can delete this action.

CHANGELOG.rst

@@ -4,7 +4,7 @@
 # You can set these variables from the command line.
 
 # Options should be aligned with how the documentation is built on RTD
-# (except for '--keep-going', failing fast is prefered on local builds)
+# (except for '--keep-going', failing fast is preferred on local builds)
 # We also remove '-E' to reduce the time of rebuilding reference indexes
 # on each build.
 SPHINXOPTS    = -T -j auto -W

docs/Makefile

@@ -42,7 +42,7 @@ Instead of trying to map a URL to a view,
 we first analyze the root project (given from the subdomain),
 and based on that we map each part of the URL to the *current* project and version.
 
-This will allow us to re-use this code in our unresolver
+This will allow us to reuse this code in our unresolver
 without the need to override the Django's urlconf at runtime,
 or guessing a project only by the structure of its URL.
 

docs/dev/design/better-doc-urls-handling.rst

@@ -265,7 +265,7 @@ and we can roll back if the new pre-compiled version was built with a problem.
 
    Installing always the latest version is harder to maintain.
    It will require building the newest version each time a new patch version is released.
-   Beacause of that, Read the Docs will always be behind official releases.
+   Because of that, Read the Docs will always be behind official releases.
    Besides, it will give projects different versions more often.
 
    Exposing to the user the patch version would require to cache many different versions ourselves,
@@ -424,10 +424,10 @@ that doesn't seem to be useful to have the same OS version with different states
 Allowing users to install extra languages by using the Config File will cover most of the support requests we have had in the past.
 It also will allow us to know more about how our users are using the platform to make future decisions based on this data.
 Exposing users how we want them to use our platform will allow us to be able to maintain it longer,
-than giving the option to select a specific Docker image by name that we can't guarrantee it will be frozen.
+than giving the option to select a specific Docker image by name that we can't guarantee it will be frozen.
 
 Finally, having the ability to deprecate and *remove* pre-built images from our builders over time,
-will reduce the maintainance work required from the the core team.
+will reduce the maintenance work required from the the core team.
 We can always support all the languages versions by installing them at build time.
 The only required pre-built image for this are the OS ``-base`` images.
 In fact, even after decided to deprecate and removed a pre-built image from the builders,

docs/dev/design/build-images.rst

@@ -34,7 +34,7 @@ Goals
 * Ability to add non-error notifications from the build process
 * Add extra metadata associated to the notification: icon, header, body, etc
 * Support different types of notifications (e.g. error, warning, note, tip)
-* Re-use the new notification system for product updates (e.g. new features, deprecated config keys)
+* Reuse the new notification system for product updates (e.g. new features, deprecated config keys)
 * Message content lives on Python classes that can be translated and formatted with objects (e.g. Build, Project)
 * Message could have richer content (e.g. HTML code) to generate links and emphasis
 * Notifications have trackable state (e.g. unread (default)=never shown, read=shown, dismissed=don't show again, cancelled=auto-removed after user action)
@@ -43,7 +43,7 @@ Goals
 * Notifications can be attached to Project, Organization, Build and User models
 * Specific notifications can be shown under the user's bell icon
 * Easy way to cleanup notification on status changes (e.g. subscription failure notification is auto-deleted after CC updated)
-* Notifications attached to Organization/Project dissappear for all the users once they are dismissed by anyone
+* Notifications attached to Organization/Project disappear for all the users once they are dismissed by anyone
 
 
 Non-goals
@@ -88,7 +88,7 @@ This section shows all the classes and models involved for the notification syst
 .. note:: Accessing the database from the build process
 
     Builders doesn't have access to the database due to security reasons.
-    We had solved this limitation by creating an API endpoint the builder hits once they need to interact with the databse to get a ``Project``, ``Version`` and ``Build`` resources, create a ``BuildCommand`` resource, etc.
+    We had solved this limitation by creating an API endpoint the builder hits once they need to interact with the database to get a ``Project``, ``Version`` and ``Build`` resources, create a ``BuildCommand`` resource, etc.
 
     Besides, the build process is capable to trigger Celery tasks that are useful for managing more complex logic
     that also require accessing from and writing to the database.
@@ -116,7 +116,7 @@ and some helper logic to return in the API response.
             body = str
             icon = str
             icon_style = str(SOLID, DUOTONE)
-            type = str(ERROR, WARINIG, NOTE, TIP)
+            type = str(ERROR, WARNING, NOTE, TIP)
 
         def get_display_icon(self):
             if self.icon:
@@ -201,7 +201,7 @@ It contains an identifier (``message_id``) pointing to one of the messages defin
         message_id = models.CharField(max_length=128)
 
         # UNREAD: the notification was not shown to the user
-        # READ: the notifiation was shown
+        # READ: the notification was shown
         # DISMISSED: the notification was shown and the user dismissed it
         # CANCELLED: removed automatically because the user has done the action required (e.g. paid the subscription)
         state = models.CharField(
@@ -210,7 +210,7 @@ It contains an identifier (``message_id``) pointing to one of the messages defin
             db_index=True,
         )
 
-        # Makes the notification imposible to dismiss (useful for Build notifications)
+        # Makes the notification impossible to dismiss (useful for Build notifications)
         dismissable = models.BooleanField(default=False)
 
         # Show the notification under the bell icon for the user

docs/dev/design/new-notifications-system.rst

@@ -139,7 +139,7 @@ like the projects, versions, and the query that were used in the final search.
 And the ``version``, ``project``, and ``project_alias`` attributes will
 now be objects.
 
-We could just re-use the old response too,
+We could just reuse the old response too,
 since the only breaking changes would be the attributes now being objects,
 and we aren't adding any new information to those objects (yet).
 But also, re-using the current serializers shouldn't be a problem either.
@@ -230,7 +230,7 @@ the readthedocs.org/readthedocs.com domains.
 We have two types:
 
 Project scoped search:
-   Search files and versions of the curent project only.
+   Search files and versions of the current project only.
 
 Global search:
    Search files and versions of all projects in .org,

docs/dev/design/new-search-api.rst

@@ -43,7 +43,7 @@ We might consider adding a ``VERSION_TYPES`` to the ``Version`` model.
 - If we go with ``VERSION_TYPES`` we can add something like ``pull_request`` alongside Tag and Branch.
 
 We should add ``Version`` and ``Build`` Model Managers for PR and Regular Versions and Builds.
-The proposed names for PR and Regular Version and Build Mangers are ``external`` and ``internal``.
+The proposed names for PR and Regular Version and Build Managers are ``external`` and ``internal``.
 
 We can then use ``Version.internal.all()`` to get all regular versions,
 ``Version.external.all()`` to get all PR versions.

docs/dev/design/pr-builder.rst

@@ -98,7 +98,7 @@ Why attach tokens to users?
 ---------------------------
 
 Attaching tokens to users will ease the implementation,
-since we can re-use the code from knox package.
+since we can reuse the code from knox package.
 
 Attaching tokens to projects only is possible,
 but it will require to manage the authentication manually.
@@ -108,7 +108,7 @@ An alternative is to use the DRF API key package, which doesn't require a user,
 but then if we wanted to extend this functionality to our normal APIs, we will have
 to implement the authentication manually.
 
-Kepping backwards compatibility
+Keeping backwards compatibility
 -------------------------------
 
 Access to write API V2 is restricted to superusers,
@@ -161,7 +161,7 @@ since it also handles authentication).
 Decision
 --------
 
-Due to the fact that the required featues from knox are not released yet,
+Due to the fact that the required features from knox are not released yet,
 we have decided to use DRF API key instead.
 
 Future work