Link in the new contributors guide for RTD

Tweaks to the developer guide

Author: tennlee

docs/devguide.md

@@ -1,22 +1,14 @@
-# PyEarthTools Core Developer Guide
+# PyEarthTools Developer Guide
 
-This is a summary only, and should be expanded to provide more detail. This is intended to provide succinct guidance to the team of people directly involved in coding the PyEarthTools framework. Other guides will be produced for other contributor demographics (such as those involved in producing documentation, tutorials, or other kinds of contribution).
+This is a summary only, and should be expanded to provide more detail. This is intended to provide succinct guidance to those who want to contribute code to PyEarthTools.
 
 ## Quick Overview
 
 - Please fork the repository and do your development on your fork. Create pull requests from your fork.
+- Use feature branches on your fork, and use a unique branch for every pull request.
 - Unit test coverage on new pull requests should meet or extend existing levels of test coverage.
-
-
-## Coding Guidelines
-
-- Use 'black' and 'isort' with a line length of 120 characters
-
-## Nice-to-haves
-
-- Type hints would be nice, but the development so far hasn't required them. Do your best.
-- Pylint checking is a good idea, please turn it on and do your best.
-
+- We use 'black' and 'ruff check' and supply configuration files for each.
+- Type hints are not required.
 
 ## Creating Your Own Fork of PyEarthTools for the First Time
 
@@ -26,7 +18,6 @@ Unless you are an advanced Git user, we would recommend you follow this process:
 2. Clone **your fork**. (Do not directly clone https://github.com/ACCESS-Community-Hub/PyEarthTools).
 3. Immediately create a new local branch, with a command such as `git checkout -b branch_name`.
 
-
 ## Workflow for Submitting Pull Requests
 
 Prior to developing a pull request, it may be a good idea to create a GitHub issue to capture what the pull request is trying to achieve, any pertinent details, and (if applicable) how it aligns to the roadmap. Otherwise, please explain this in the pull request.
@@ -63,7 +54,6 @@ A code review is responsible for checking the following:
 6. Code does not do anything unexpected or beyond the scope of the function
 7. Any additional dependencies are justified and do not result in bloat
 
-
 ## GitHub Actions - Workflows
 We are using GitHub actions to automate testing and specific workflows.
 1. **Black** - Python code formatting. [https://pypi.org/project/black/](https://pypi.org/project/black/)

docs/index.md

@@ -151,6 +151,7 @@ data
 config
 api/api
 roadmap
+contributing
 devguide
 maintainer
 ```