MINOR: [Docs] Fix typos in rst files (#46335)

### Rationale for this change
Improving docs by removing typos
### What changes are included in this PR?
Fix typos in rst files
### Are these changes tested?
Documentation-only changes
### Are there any user-facing changes?
Documentation-only changes

Authored-by: omahs <[email protected]>
Signed-off-by: Sutou Kouhei <[email protected]>

Author: omahs

docs/source/cpp/env_vars.rst

@@ -145,7 +145,7 @@ that changing their value later will have an effect.
 
    By default, Arrow C++ detects the capabilities of the current CPU at runtime
    and chooses the best execution paths based on that information.  This
-   behavior can be overriden by setting this environment variable to a
+   behavior can be overridden by setting this environment variable to a
    well-defined value.  Supported values are:
 
    - ``NONE`` disables any runtime-selected SIMD optimization;

docs/source/developers/benchmarks.rst

@@ -159,9 +159,9 @@ Writing a benchmark
    By contrast to realtime which is the wall clock time, e.g. the difference
    between end_time - start_time. In a single thread model, the cputime is
    preferable since it is less affected by context switching. In a multi thread
-   scenario, the cputime will give incorrect result since the since it'll
-   be inflated by the number of threads and can be far off realtime. Thus, if
-   the benchmark is multi threaded, it might be better to use
+   scenario, the cputime will give incorrect result since it'll be inflated by
+   the number of threads and can be far off realtime. Thus, if the benchmark is
+   multi threaded, it might be better to use
    ``SetRealtime()``, see this `example <https://github.com/apache/arrow/blob/a9582ea6ab2db055656809a2c579165fe6a811ba/cpp/src/arrow/io/memory-benchmark.cc#L223-L227>`_.
 
 Scripting

docs/source/developers/bug_reports.rst

@@ -200,7 +200,7 @@ reached a terminal status, it is closed with one of two outcomes:
 
   If you are merging a PR it is good practice to add a comment
   to the linked issue about which PR is resolving it. This way
-  GitHub crates a notification for anybody that collaborated on
+  GitHub creates a notification for anybody that collaborated on
   the issue.
 
 * **closed as not planned** - indicates the issue is closed and should

docs/source/developers/continuous_integration/overview.rst

@@ -24,11 +24,11 @@ Continuous Integration for Arrow is fairly complex as it needs to run across dif
 
 Some files central to Arrow CI are:
 
-- ``docker-compose.yml`` - here we define docker services which can be configured using either enviroment variables, or the default values for these variables.
+- ``docker-compose.yml`` - here we define docker services which can be configured using either environment variables, or the default values for these variables.
 - ``.env`` - here we define default values to configure the services in ``docker-compose.yml``
 - ``appveyor.yml`` - here we define workflows that run on Appveyor
 
-We use :ref:`Docker<docker-builds>` in order to have portable and reproducible Linux builds, as well as running Windows builds in Windows containers.  We use :ref:`Archery<Archery>` and :ref:`Crossbow<Crossbow>` to help co-ordinate the various CI tasks.
+We use :ref:`Docker<docker-builds>` in order to have portable and reproducible Linux builds, as well as running Windows builds in Windows containers.  We use :ref:`Archery<Archery>` and :ref:`Crossbow<Crossbow>` to help coordinate the various CI tasks.
 
 One thing to note is that some of the services defined in ``docker-compose.yml`` are interdependent.  When running services locally, you must either manually build its dependencies first, or build it via the use of ``archery docker run ...`` which automatically finds and builds dependencies.
 
@@ -69,6 +69,6 @@ Crossbow is a subcomponent of Archery and can be used to manually trigger builds
 - the file ``dev/tasks/tasks.yml`` containing the configuration for various tasks which can be run via Crossbow
 - subdirectories containing different task templates (specified using `jinja2 syntax <https://jinja.palletsprojects.com/>`_), divided roughly by language or package management system.
 
-Most of these tasks are run as part of the nightly builds, though they can also be triggered manually by add a comment to a PR which begins with ``@github-actions crossbow submit`` followed by the name of the task to be run.
+Most of these tasks are run as part of the nightly builds, though they can also be triggered manually by adding a comment to a PR which begins with ``@github-actions crossbow submit`` followed by the name of the task to be run.
 
 For convenience purpose, the tasks in ``dev/tasks/tasks.yml`` are defined in groups, which makes it simpler for multiple tasks to be submitted to Crossbow at once.  The task definitions here contain information about which service defined in ``docker-compose.yml`` to run, the CI service to run the task on, and which template file to use as the basis for that task.

docs/source/developers/python.rst

@@ -646,7 +646,7 @@ PyArrow are:
      - Number of processes used to compile PyArrow’s C++/Cython components
      - ``''``
 
-The components being disabled or enabled when building PyArrrow is by default
+The components being disabled or enabled when building PyArrow is by default
 based on how Arrow C++ is build (i.e. it follows the ``ARROW_$COMPONENT`` flags).
 However, the ``PYARROW_WITH_$COMPONENT`` environment variables can still be used
 to override this when building PyArrow (e.g. to disable components, or to enforce

docs/source/developers/release.rst

@@ -107,11 +107,11 @@ for specific builds and others.
 Any developer can ask for a patch release to be generated sending an email to the
 `Arrow development mailing-list <https://arrow.apache.org/community/>`__ with the reason
 of why a new release is necessary.
-If there is consensus and there is a Release Manager willing to take the effort to create
+If there is consensus and there is a Release Manager willing to make the effort to create
 the release a patch release can be created.
 
 Committers can tag issues that should be included on the next patch release using the
-``backport-candidate`` label. Is the responsability of the author or the committer to add the
+``backport-candidate`` label. Is the responsibility of the author or the committer to add the
 label to the issue to help the Release Manager identify the issues that should be backported.
 
 If a specific issue is identified as the reason to create a patch release the Release Manager
@@ -185,7 +185,7 @@ Some release managers prefer to perform testing before creating the first
 release candidate to avoid the need to create multiple release candidates within
 a given release.
 
-To test before creating a release candiate:
+To test before creating a release candidate:
 
 * Create a pull request from the up-to-date maint-X.Y.Z branch onto main
 * Title the pull request "WIP: Dummy PR to check maint-X.Y.Z status"

docs/source/format/DissociatedIPC.rst

@@ -359,7 +359,7 @@ showing how a client might handle the metadata and data streams:
    be used alongside the sequence number to match the message regardless of the higher bytes (e.g. we only
    care about matching the lower 4 bytes to the sequence number)
 
-   * Once recieved, the Most Significant Byte's value determines how the client processes the body data:
+   * Once received, the Most Significant Byte's value determines how the client processes the body data:
 
      * If the most significant byte is 0: Then the body of the message is the raw IPC packed body buffers
        allowing it to easily be processed with the corresponding metadata header bytes.