Added linting in developer guides

Author: kanhereashwin

docs/source/contributing/development.rst

@@ -3,9 +3,12 @@
 Development Guides
 ==================
 
-Here are a set of detailed guides depending on if you are a public user,
-Stanford NAV Lab member, or a project maintainer.
+Here are a set of detailed guides depending on if you are a :ref:`public user<standard_dev>`,
+:ref:`Stanford NAV Lab member<navlab_dev>`, or a project maintainer
+:ref:`reviewing pull requests<pr_review>` or
+:ref:`creating new release branches<release_workflow>`.
 
+.. _standard_dev:
 
 Standard GitHub Workflow
 ------------------------
@@ -44,17 +47,15 @@ Standard GitHub Workflow
 6. Add tests for the newly added code and ensure the new code is covered.
    See the :ref:`Testing<testing>` section for more details.
 
-7. Add your name to the `contributors list <https://github.com/Stanford-NavLab/gnss_lib_py/blob/main/CONTRIBUTORS.sh>`__.
-
-8. When you're done making changes run all the tests with:
+7. When you're done making changes run all the tests with:
 
    .. code-block:: bash
 
       poetry run pytest
 
    Make sure that all tests are passing.
 
-9. Verify that testing coverage has not decreased:
+8. Verify that testing coverage has not decreased:
 
    .. code-block:: bash
 
@@ -63,19 +64,34 @@ Standard GitHub Workflow
 
    See the :ref:`Coverage Report<coverage>` section for more details.
 
+9. Improve code readability by linting it. Run :code:`pylint` to preview
+   issues with the code:
+
+   .. code-block:: bash
+
+      poetry run python -m pylint path-to-file-to-lint
+
+   Resolve issues that do not impact how you have implemented your functionality,
+   such as conforming to snake case naming, removing TODOs and using suggested
+   defaults.
+
 10. Ensure that system and IDE dependent files, like those in :code:`.idea`
     folders for PyCharm and :code:`.vscode` folders for VS Code are not
     committed by updating the :code:`.gitignore` file.
 
-11. Commit your changes and publish your branch to GitHub:
+11. Add your name to the `contributors list <https://github.com/Stanford-NavLab/gnss_lib_py/blob/main/CONTRIBUTORS.sh>`__.
+
+12. Commit your changes and publish your branch to GitHub:
 
    .. code-block:: bash
 
       git add -A
       git commit -m "<describe changes in this commit>"
       git push origin your-name/name-of-your-bugfix-or-feature
 
-12. Submit a pull request through GitHub.
+13. Submit a pull request through GitHub.
+
+.. _navlab_dev:
 
 NAVLab GitHub Workflow
 ----------------------
@@ -126,11 +142,22 @@ NAVLab GitHub Workflow
    folders for PyCharm and :code:`.vscode` folders for VS Code are not
    committed by updating the :code:`.gitignore` file.
 
-9. When you're ready to commit changes follow the steps below to
-   minimize unnecessary merging. This is especially important if
-   multiple people are working on the same branch. If you pull new
-   changes, then repeat the tests above to double check that everything
-   is still working as expected.
+9. Improve code readability by linting it. Run :code:`pylint` to preview
+   issues with the code:
+
+   .. code-block:: bash
+
+      poetry run python -m pylint path-to-file-to-lint
+
+   Resolve issues that do not impact how you have implemented your functionality,
+   such as conforming to snake case naming, removing TODOs and using suggested
+   defaults.
+
+10. When you're ready to commit changes follow the steps below to
+    minimize unnecessary merging. This is especially important if
+    multiple people are working on the same branch. If you pull new
+    changes, then repeat the tests above to double check that everything
+    is still working as expected.
 
    .. code-block:: bash
 
@@ -141,11 +168,16 @@ NAVLab GitHub Workflow
       git commit -m "<describe changes in this commit>"
       git push origin your-name/name-of-your-bugfix-or-feature
 
-10. Submit a pull request through the GitHub website. In the pull request,
+11. Submit a pull request through the GitHub website. For the base branch
+    in the pull request, select the latest version release branch :code:`vx.Y.Z`
+    (with the highest number of all such branches). *Do not target the*
+    :code:`main` *branch in your pull request.* In the pull request,
     add a code review request for the current maintainers of the repository,
-    Ashwin Kanhere, Derek Knowles or Sriramya Bhamidipati. The reviewers
+    Ashwin Kanhere or Derek Knowles. The reviewers
     might add comments to ensure compliance with the rest of the code.
 
+.. _pr_review:
+
 Pull Request Review Workflow
 ----------------------------
 
@@ -203,16 +235,24 @@ Pull Request Review Workflow
 
    See the :ref:`Coverage Report<coverage>` section for more details.
 
-7. Submit your approval or any comments on GitHub.
+7. Verify that the Pull Request targets the latest version release branch,
+   called :code:`vX.Y.Z`. If it doesn't target this branch, change the base
+   branch to the latest version release branch. If this branch
+   doesn't exist, create the latest version release branch from :code:`main`
+   before changing the base.
+
+8. Submit your approval or any comments on GitHub.
+
+.. _release_workflow:
 
 New Package Release Workflow
 ----------------------------
 
-1. Create new branch for the release:
+1. Switch to the latest version release branch (with the highest number):
 
    .. code-block:: bash
 
-      git checkout -b your-name/release-X.Y.Z
+      git checkout -b vX.Y.Z
 
 2. Open the ``pyproject.toml`` file and under the ``[tool.poetry]``
    group change the ``version = X.Y.Z`` variable to match the new