fix link issues and typos

docs/developer/CI.rst

@@ -6,7 +6,7 @@ CI (Continuous Integration)
 ===========================
 
 Our CI system is designed to automate testing and ensure that every change meets our coding styles. 
-If you are familiar with github actions, you may find our workflow `here<https://github.com/kokkos/kokkos-fft/blob/main/.github/workflows/build_test.yaml>`_.
+If you are familiar with github actions, you may find our workflow `here <https://github.com/kokkos/kokkos-fft/blob/main/.github/workflows/build_test.yaml>`_.
 The CI process includes:
 
 - **Linting and Style Checks:** Verifying that the code follows to our style guidelines.
@@ -20,7 +20,7 @@ We have four CIs for formatting: ``reuse``, ``clang-format``, ``cmake-format`` a
 
 #. **License Check with Reuse:**  
    All the files in the repo need to include copyright and license information at the top.
-   These are automatically confirmed with `REUSE compilance check<https://reuse.software>`_ in CI.
+   These are automatically confirmed with `REUSE compliance check <https://reuse.software>`_ in CI.
    If there is a file without the copyright, the REUSE CI will fail and notify which file misses a copyright.
    The copyright statement in ``CMakeLists.txt`` is given in the following manner.
 
@@ -37,31 +37,33 @@ We have four CIs for formatting: ``reuse``, ``clang-format``, ``cmake-format`` a
    To format a C++ file, please apply the following command
 
    .. code-block:: bash
-   clang-format -i <cppfile_you_have_modified>
 
-   Format are automatically confirmed with `clang-format check<https://clang.llvm.org/docs/ClangFormat.html>`_ in CI.
+      clang-format -i <cppfile_you_have_modified>
+
+   Format are automatically confirmed with `clang-format check <https://clang.llvm.org/docs/ClangFormat.html>`_ in CI.
    If further formatting is needed, the clang-format CI will fail and notify which file needs to be modified.
 
 #. **CMake formatting with cmake-format:**  
    All the CMake files (``CMakeLists.txt`` and ``.cmake`` files) in the repo shall be formatted with cmake-format.
    To format a CMake file, please apply the following command
 
    .. code-block:: bash
-   cmake-format --in-place
 
-   Format are automatically confirmed with `cmake-format check<https://github.com/cheshirekow/cmake_format>`_ in CI.
+      cmake-format --in-place
+
+   Format are automatically confirmed with `cmake-format check <https://github.com/cheshirekow/cmake_format>`_ in CI.
    If further formatting is needed, the cmake-format CI will fail and notify which file needs to be modified.
 
 #. **Spell check with typos:**  
-   Spell errors are checked with `typos<https://github.com/crate-ci/typos>`_ in CI. 
+   Spell errors are checked with `typos <https://github.com/crate-ci/typos>`_ in CI.
    If potential typos are detected, they will report typos with suggestions.
 
 Build Verification
 ------------------
 
 Compilation tests are performed inside containers for each backend including NVIDIA, AMD and Intel GPUs
 (see `Dockerfiles <https://github.com/kokkos/kokkos-fft/tree/main/docker>`_).
-These images are useful to develop locally particulaly when you are interested in modifying the
+These images are useful to develop locally particularly when you are interested in modifying the
 backend specific codes. In other word, if you develop and test your code inside these containers, 
 your PR will likely to pass our CI. For each backend, we test to compile a simple test code by using kokkos-fft as CMake subdirectory or installed library. 
 

docs/developer/contributing.rst

@@ -9,12 +9,10 @@ We briefly explain the workflow to contribute by making a pull request (PR) agai
 Followings are the steps to contribute the project:
 
 #. **Report bugs or Suggest features:**
-
-First open issues or ask questions on the Kokkos slack channel.
+   First open issues or ask questions on the Kokkos slack channel.
 
 #. **Fork the Repository:**
-
-Click the "Fork" button on our `repo<https://github.com/kokkos/kokkos-fft>`_ to create your own copy.
+   Click the "Fork" button on our `repo <https://github.com/kokkos/kokkos-fft>`_ to create your own copy.
 
 #. **Clone Your Fork:**  
    Clone the repository to your local machine with submodules.
@@ -32,8 +30,7 @@ Click the "Fork" button on our `repo<https://github.com/kokkos/kokkos-fft>`_ to
       git remote add upstream https://github.com/kokkos/kokkos-fft.git   
 
 #. **Create a New Branch:**
-
-Create a new branch for your feature or bug fix with a descriptive name:
+   Create a new branch for your feature or bug fix with a descriptive name:
 
    .. code-block:: bash
 
@@ -55,7 +52,7 @@ Create a new branch for your feature or bug fix with a descriptive name:
          git rebase upstream/main
 
 #. **Make Your Changes:**  
-   Implement your feature or bug fix. Ensure you adhere to the project's coding standards and guidelines (see :doc:`details of CI<developer/CI>`).
+   Implement your feature or bug fix. Ensure you adhere to the project's coding standards and guidelines (see :doc:`details of CI<CI>`).
 
 #. **Commit Your Changes:**  
    Stage your changes and commit them with a clear, concise commit message:
@@ -73,7 +70,7 @@ Create a new branch for your feature or bug fix with a descriptive name:
       git push --force-with-lease origin <feature-name>
 
 #. **Open a Pull Request:**  
-   On `GitHub<https://github.com/kokkos/kokkos-fft>`_, open a PR from your branch to the original repository's ``main`` branch.
+   On `GitHub <https://github.com/kokkos/kokkos-fft>`_, open a PR from your branch to the original repository's ``main`` branch.
    Include a detailed description of your changes and reference any related issues.
 
 #. **Participate in the Code Review:**  

docs/developer/documentation.rst

@@ -5,7 +5,7 @@
 Documentation
 =============
 
-We deploy the `kokkos-fft website<https://kokkosfft.readthedocs.io/>`_ on readthedocs. 
+We deploy the `kokkos-fft website <https://kokkosfft.readthedocs.io/>`_ on readthedocs.
 The API references are auto generated by doxygen to ensure that the API documentation is always up-to-date with the source code.
 
 Documentation Structure
@@ -52,15 +52,15 @@ API Reference
 -------------
 
 API reference is auto-generated from docstrings within the C++ source code. 
-Thus, all APIs must to be documented with `doxygen style docstrings<https://www.doxygen.nl/manual/docblocks.html>`_.
+Thus, all APIs must to be documented with `doxygen style docstrings <https://www.doxygen.nl/manual/docblocks.html>`_.
 To ensure accuracy and consistency:
 
 #. **Write Clear and Consistent Docstrings:**  
    Use descriptive and clear docstrings for all APIs including functions and classes. Each docstring should include:
    - A brief description of the purpose.
    - Descriptions of parameters and return values.
 
-   Here is an example of docstrings for a function (rendered version is found `here<https://kokkosfft.readthedocs.io/en/latest/api/helper/fftfreq.html>`_).
+   Here is an example of docstrings for a function (rendered version is found `here <https://kokkosfft.readthedocs.io/en/latest/api/helper/fftfreq.html>`__).
 
    .. code-block:: C++
 
@@ -78,7 +78,7 @@ To ensure accuracy and consistency:
      auto fftfreq(const ExecutionSpace&, const std::size_t n,
                   const RealType d = 1.0) {
 
-   A class definition should be documented in the following manner (rendered version is found `here<https://kokkosfft.readthedocs.io/en/latest/api/plan/plan.html>`_).
+   A class definition should be documented in the following manner (rendered version is found `here <https://kokkosfft.readthedocs.io/en/latest/api/plan/plan.html>`__).
    Class methods can be documented in the same way as functions.
 
    .. code-block:: C++
@@ -100,8 +100,8 @@ To ensure accuracy and consistency:
 
 #. **Make a ReStructuredText file:**  
    To generate documentations only for APIs, we place functions and/or classes in the ReStructuredText (rst) file. 
-   Here are the examples for a function and a class (rendered versions are found at `here<https://kokkosfft.readthedocs.io/en/latest/api/helper/fftfreq.html>`_ and `here<https://kokkosfft.readthedocs.io/en/latest/api/plan/plan.html>`_).
-   For overloaded functions, you need to also describe the arugments of the function.
+   Here are the examples for a function and a class (rendered versions are found at `here <https://kokkosfft.readthedocs.io/en/latest/api/helper/fftfreq.html>`__ and `here <https://kokkosfft.readthedocs.io/en/latest/api/plan/plan.html>`__).
+   For overloaded functions, you need to also describe the arguments of the function.
 
    .. code-block:: rst
       

docs/developer/review.rst

@@ -5,13 +5,13 @@
 Reviews
 =======
 Code review is an essential part of our development process. It is always appreciated to first open issues or ask questions on the 
-Kokkos slack channel before making PRs. A "good" PR is detailed in `the kokkos documentation<https://kokkos.org/kokkos-core-wiki/developer-guides/prs-and-reviews.html>`_.
+Kokkos slack channel before making PRs. A "good" PR is detailed in `the kokkos documentation <https://kokkos.org/kokkos-core-wiki/developer-guides/prs-and-reviews.html>`_.
 
 When your pull request is ready for review, please:
 
 - **PR Description:** Ensure your PR description includes the context for the changes.
 - **Formatting:** Format your code following :doc:`our guideline<CI>`.
 - **Adding unit-tests:** If your PR adds a new feature, add unit-tests for that feature (see :doc:`details of CI<CI>`).
-- **Adding docstrings:** Add `doxygen style docstrings<https://www.doxygen.nl/manual/docblocks.html>`_ for APIs. 
+- **Adding docstrings:** Add `doxygen style docstrings <https://www.doxygen.nl/manual/docblocks.html>`_ for APIs.
 - **Responding to Feedback:** Actively communiate with reviewers and address any feedback.
 - **Approval Process:** Wait for approval from one or more core reviewers.