Remove "bad characters" from our codebase (#24841)

* Remove "bad characters" from our codebase

We had plenty of "bad characters" in our codebase that were not
invited and came here by accident. We want to get rid of those
"bad characters" once and for all.

.github/boring-cyborg.yml

@@ -216,7 +216,7 @@ firstPRWelcomeComment: >
   Consider adding an example DAG that shows how users should use it.
 
   - Consider using [Breeze environment](https://github.com/apache/airflow/blob/main/BREEZE.rst) for testing
-  locally, it’s a heavy docker but it ships with a working Airflow and a lot of integrations.
+  locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
 
   - Be patient and persistent. It might take some time to get a review or get the final approval from
   Committers.

.pre-commit-config.yaml

@@ -42,9 +42,6 @@ repos:
   - repo: https://github.com/Lucas-C/pre-commit-hooks
     rev: v1.2.0
     hooks:
-      - id: forbid-tabs
-        name: Fail if tabs are used in the project
-        exclude: ^airflow/_vendor/|^clients/gen/go\.sh$|^\.gitmodules$
       - id: insert-license
         name: Add license for all SQL files
         files: \.sql$
@@ -303,6 +300,13 @@ repos:
           - --exclude-file=.codespellignorelines
   - repo: local
     hooks:
+      - id: replace-bad-characters
+        name: Replace bad characters
+        entry: ./scripts/ci/pre_commit/pre_commit_replace_bad_characters.py
+        language: python
+        types: [file, text]
+        exclude: ^airflow/_vendor/|^clients/gen/go\.sh$|^\.gitmodules$
+        additional_dependencies: ['rich>=12.4.4']
       - id: static-check-autoflake
         name: Remove all unused code
         entry: autoflake --remove-all-unused-imports --ignore-init-module-imports --in-place
@@ -353,7 +357,7 @@ repos:
         name: Update output of breeze commands in BREEZE.rst
         entry: ./scripts/ci/pre_commit/pre_commit_breeze_cmd_line.py
         language: python
-        files: ^BREEZE\.rst$|^dev/breeze/.*$
+        files: ^BREEZE\.rst$|^dev/breeze/.*$|^\.pre-commit-config\.yml$
         pass_filenames: false
         additional_dependencies: ['rich>=12.4.4', 'rich-click>=1.5']
       - id: update-local-yml-file

COMMITTERS.rst

@@ -27,7 +27,7 @@ Before reading this document, you should be familiar with `Contributor's guide <
 Guidelines to become an Airflow Committer
 ------------------------------------------
 
-Committers are community members who have write access to the project’s
+Committers are community members who have write access to the project's
 repositories, i.e., they can modify the code, documentation, and website by themselves and also
 accept other contributions. There is no strict protocol for becoming a committer. Candidates for new
 committers are typically people that are active contributors and community members.
@@ -77,7 +77,7 @@ Community contributions
 
 1.  Was instrumental in triaging issues
 2.  Improved documentation of Airflow in significant way
-3.  Lead change and improvements introduction in the “community” processes and tools
+3.  Lead change and improvements introduction in the "community" processes and tools
 4.  Actively spreads the word about Airflow, for example organising Airflow summit, workshops for
     community members, giving and recording talks, writing blogs
 5.  Reporting bugs with detailed reproduction steps

CONTRIBUTING.rst

@@ -134,7 +134,7 @@ and guidelines.
 Committers/Maintainers
 ----------------------
 
-Committers are community members that have write access to the project’s repositories, i.e., they can modify the code,
+Committers are community members that have write access to the project's repositories, i.e., they can modify the code,
 documentation, and website by themselves and also accept other contributions.
 
 The official list of committers can be found `here <https://airflow.apache.org/docs/apache-airflow/stable/project.html#committers>`__.
@@ -277,7 +277,7 @@ For effective collaboration, make sure to join the following Airflow groups:
 
 - Mailing lists:
 
-  - Developer’s mailing list `<dev-subscribe@airflow.apache.org>`_
+  - Developer's mailing list `<dev-subscribe@airflow.apache.org>`_
     (quite substantial traffic on this list)
 
   - All commits mailing list: `<commits-subscribe@airflow.apache.org>`_
@@ -1472,14 +1472,14 @@ Here are a few rules that are important to keep in mind when you enter our commu
 * There is a #newbie-questions channel in slack as a safe place to ask questions
 * You can ask one of the committers to be a mentor for you, committers can guide within the community
 * You can apply to more structured `Apache Mentoring Programme <https://community.apache.org/mentoringprogramme.html>`_
-* It’s your responsibility as an author to take your PR from start-to-end including leading communication
+* It's your responsibility as an author to take your PR from start-to-end including leading communication
   in the PR
-* It’s your responsibility as an author to ping committers to review your PR - be mildly annoying sometimes,
-  it’s OK to be slightly annoying with your change - it is also a sign for committers that you care
+* It's your responsibility as an author to ping committers to review your PR - be mildly annoying sometimes,
+  it's OK to be slightly annoying with your change - it is also a sign for committers that you care
 * Be considerate to the high code quality/test coverage requirements for Apache Airflow
 * If in doubt - ask the community for their opinion or propose to vote at the devlist
 * Discussions should concern subject matters - judge or criticise the merit but never criticise people
-* It’s OK to express your own emotions while communicating - it helps other people to understand you
+* It's OK to express your own emotions while communicating - it helps other people to understand you
 * Be considerate for feelings of others. Tell about how you feel not what you think of others
 
 Commit Policy
@@ -1495,6 +1495,6 @@ and slightly modified and consensus reached in October 2020:
 
 Resources & Links
 =================
-- `Airflow’s official documentation <https://airflow.apache.org/>`__
+- `Airflow's official documentation <https://airflow.apache.org/>`__
 
 - `More resources and links to Airflow related content on the Wiki <https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Links>`__

IMAGES.rst

@@ -382,7 +382,7 @@ The following build arguments (``--build-arg`` in docker build command) can be u
 | ``HOME``                                 | ``/root``                                | Home directory of the root user (CI      |
 |                                          |                                          | image has root user as default)          |
 +------------------------------------------+------------------------------------------+------------------------------------------+
-| ``AIRFLOW_HOME``                         | ``/root/airflow``                        | Airflow’s HOME (that’s where logs and    |
+| ``AIRFLOW_HOME``                         | ``/root/airflow``                        | Airflow's HOME (that's where logs and    |
 |                                          |                                          | sqlite databases are stored)             |
 +------------------------------------------+------------------------------------------+------------------------------------------+
 | ``AIRFLOW_SOURCES``                      | ``/opt/airflow``                         | Mounted sources of Airflow               |

ISSUE_TRIAGE_PROCESS.rst

@@ -44,16 +44,16 @@ to indicate the following elements:
 
 **Kind**
 
-The “kind” labels indicate “what kind of issue it is”. The most
-commonly used “kind” labels are: bug, feature, documentation, or task.
+The "kind" labels indicate "what kind of issue it is". The most
+commonly used "kind" labels are: bug, feature, documentation, or task.
 
 Therefore, when reporting an issue, the label of ``kind:bug`` is to
 indicate a problem with the functionality, whereas the label of
 ``kind:feature`` is a desire to extend the functionality.
 
 There has been discussion within the project about whether to separate
-the desire for “new features” from “enhancements to existing features”,
-but in practice most “feature requests” are actually enhancement requests,
+the desire for "new features" from "enhancements to existing features",
+but in practice most "feature requests" are actually enhancement requests,
 so we decided to combine them both into ``kind:feature``.
 
 The ``kind:task`` is used to categorize issues which are
@@ -67,15 +67,15 @@ made to the documentation within the project.
 
 **Area**
 
-The “area” set of labels should indicate the component of the code
+The "area" set of labels should indicate the component of the code
 referenced by the issue. At a high level, the biggest areas of the project
 are: Airflow Core and Airflow Providers, which are referenced by ``area:core``
 and ``area:providers``. This is especially important since these are now
 being released and versioned independently.
 
 There are more detailed areas of the Core Airflow project such as Scheduler, Webserver,
 API, UI, Logging, and Kubernetes, which are all conceptually under the
-“Airflow Core” area of the project.
+"Airflow Core" area of the project.
 
 Similarly within Airflow Providers, the larger providers such as Apache, AWS, Azure,
 and Google who have many hooks and operators within them, have labels directly
@@ -116,7 +116,7 @@ Therefore, the priority labels used are:
 
 It's important to use priority labels effectively so we can triage incoming issues
 appropriately and make sure that when we release a new version of Airflow,
-we can ship a release confident that there are no “production blocker” issues in it.
+we can ship a release confident that there are no "production blocker" issues in it.
 
 This applies to both Core Airflow as well as the Airflow Providers. With the separation
 of the Providers release from Core Airflow, a ``priority:critical`` bug in a single
@@ -175,13 +175,13 @@ Ideally, these issues only require one or two files to be changed. The intention
 here is that incremental changes to existing files are a lot easier for a new
 contributor as compared to adding something completely new.
 
-Another possibility here is to add “how to fix” in the comments of such issues, so
+Another possibility here is to add "how to fix" in the comments of such issues, so
 that new contributors have a running start when then pick up these issues.
 
 
 **Timeliness**
 
-For the sake of quick responses, the general “soft" rule within the Airflow project
+For the sake of quick responses, the general "soft" rule within the Airflow project
 is that if there is no assignee, anyone can take an issue to solve.
 
 However, this depends on timely resolution of the issue by the assignee. The
@@ -203,6 +203,6 @@ At times issues are marked as invalid and later closed because of one of the
 following situations:
 
 * The issue is a duplicate of an already reported issue. In such cases, the latter issue is marked as ``duplicate``.
-* Despite attempts to reproduce the issue to resolve it, the issue cannot be reproduced by the Airflow team based on the given information. In such cases, the issue is marked as ``Can’t Reproduce``.
+* Despite attempts to reproduce the issue to resolve it, the issue cannot be reproduced by the Airflow team based on the given information. In such cases, the issue is marked as ``Can't Reproduce``.
 * In some cases, the original creator realizes that the issue was incorrectly reported and then marks it as ``invalid``. Also, a committer could mark it as ``invalid`` if the issue being reported is for an unsupported operation or environment.
 * In some cases, the issue may be legitimate, but may not be addressed in the short to medium term based on current project priorities or because this will be irrelevant because of an upcoming change. The committer could mark this as ``wontfix`` to set expectations that it won't be directly addressed in the near term.