Fix duplicated and incorrect words in documentation

ISSUE_TRIAGE_PROCESS.rst

@@ -115,7 +115,7 @@ There are several actions an issue triager might take:
 
 * Assigning the issue to a milestone, if the issue seems important enough that it should likely be looked
   at before the next release but there is not enough information or doubts on why and what can be fixed.
-  Usually we assign to the the next bugfix release - then, no matter what the issue will be looked at
+  Usually we assign to the next bugfix release - then, no matter what the issue will be looked at
   by the release manager and it might trigger additional actions during the release preparation.
   This is usually followed by one of the actions below.
 

contributing-docs/18_contribution_workflow.rst

@@ -276,7 +276,7 @@ The reviewers might leave several types of responses:
   the comment, you can ask for clarifications. Generally assume good intention of the person who is reviewing
   your code and resolve conversations also having good intentions. Understand that it's not a person that
   is criticised or argued with, but rather the code and the approach. The important thing is to take care
-  about quality of the the code and the project and want to make sure that the code is good.
+  about quality of the code and the project and want to make sure that the code is good.
 
   It's ok to mark the conversation resolved by anyone who can do it - it could be the author, who thinks
   the arguments are changes implemented make the conversation resolved, or the maintainer/person who

providers/common/io/docs/xcom_backend.rst

@@ -21,8 +21,8 @@ Object Storage XCom Backend
 The default XCom backend is the :class:`~airflow.models.xcom.BaseXCom` class, which stores XComs in the Airflow database. This is fine for small values, but can be problematic for large values, or for large numbers of XComs.
 
 To enable storing XComs in an object store, you can set the ``xcom_backend`` configuration option to ``airflow.providers.common.io.xcom.backend.XComObjectStorageBackend``. You will also need to set ``xcom_objectstorage_path`` to the desired location. The connection
-id is obtained from the user part of the url the you will provide, e.g. ``xcom_objectstorage_path = s3://conn_id@mybucket/key``. Furthermore, ``xcom_objectstorage_threshold`` is required
-to be something larger than -1. Any object smaller than the threshold in bytes will be stored in the database and anything larger will be be
+id is obtained from the user part of the url that you will provide, e.g. ``xcom_objectstorage_path = s3://conn_id@mybucket/key``. Furthermore, ``xcom_objectstorage_threshold`` is required
+to be something larger than -1. Any object smaller than the threshold in bytes will be stored in the database and anything larger will be
 put in object storage. This will allow a hybrid setup. If an xcom is stored on object storage a reference will be
 saved in the database. Finally, you can set ``xcom_objectstorage_compression`` to fsspec supported compression methods like ``zip`` or ``snappy`` to
 compress the data before storing it in object storage.

providers/weaviate/docs/connections.rst

@@ -66,7 +66,7 @@ gRPC port (optional)
     The port to use for the Weaviate cluster gRPC API.
 
 Use a secure channel for the underlying gRPC API (optional)
-    Whether to use a secure channel for the the Weaviate cluster gRPC API.
+    Whether to use a secure channel for the Weaviate cluster gRPC API.
 
 
 Supported Authentication Methods