Move maintainers guide into CONTRIBUTING.md and add PR templates (#217)

Removed release steps on manually testing before a release because CI handles these tests automatically.
Release guide now suggests making a PR for updates and using the tests from those.

Removed mention of `make doctest`.
Whatever tools this relied on were never set up.
Nothing was in the doc directory to be tested.

Release guide no longer suggests adding a signature.

.github/pull_request_template.md

@@ -0,0 +1,9 @@
+### Pull Request Checklist
+
+- [ ] Read and follow the [CONTRIBUTING.md](https://github.com/matthew-brett/delocate/blob/master/CONTRIBUTING.md) guide
+- [ ] Mentioned relevant [issues](https://github.com/matthew-brett/delocate/issues)
+- [ ] Append public facing changes to [Changelog.md](https://github.com/matthew-brett/delocate/blob/master/Changelog.md)
+- [ ] Ensure new features are covered by tests
+- [ ] Ensure fixes are verified by tests
+
+<!-- describe your pull request -->

CONTRIBUTING.md

@@ -1,5 +1,7 @@
 # Contributing
 
+## Contributors guide
+
 This project uses [pre-commit](https://pre-commit.com/) hooks.
 You should install these hooks by running the following commands from the project directory:
 
@@ -8,8 +10,75 @@ pip install pre-commit
 pre-commit install
 ```
 
-Installing IDE plugins supporting [Mypy](https://mypy.readthedocs.io/en/stable/) and [Ruff](https://docs.astral.sh/ruff/) is recommend.
+Installing IDE plugins supporting [Mypy](https://mypy.readthedocs.io/en/stable/) and [Ruff](https://docs.astral.sh/ruff/) is recommend but not required.
+These will be verified by GitHub Actions during a pull request if you are unable to check them locally.
 
 Documentation follows the [Numpydoc Style Guide](https://numpydoc.readthedocs.io/en/latest/format.html).
+All public functions must have full documentation.
+All private functions must have at least a brief description.
 
 The `wheel_makers` directory holds scripts used to make test data. GitHub Actions will generate this data and upload it as an artifact named `delocate-tests-data`. This can be used to create and commit new test wheels for MacOS even if you don't have access to your own system.
+
+Use [pathlib](https://docs.python.org/3/library/pathlib.html) for any new code using paths.
+Refactor any touched functions to use pathlib when it does not break backwards compatibility.
+Prefer using `PurePosixPath` to handle relative library paths returned from MacOS tools such as `otool`.
+
+All new functions must have [type hints](https://mypy.readthedocs.io/en/stable/getting_started.html).
+All touched functions must be refactored to use type hints, including test functions.
+
+This codebase includes legacy code from the Python 2 era.
+Old code should be refactored to use modern standards when touched.
+
+## Maintainers guide
+
+This section is only relevant for maintainers with repo access.
+
+Ensure pre-commit hooks are up-to-date by running `pre-commit autoupdate`.
+
+### Guide to making a Delocate release
+
+A guide for maintainers who are doing a Delocate release.
+
+#### Release checklist
+
+- Review the open list of [issues](http://github.com/matthew-brett/delocate/issues).
+  Check whether there are outstanding issues that can be closed, and whether there are any issues that should delay the release.
+  Label them!
+
+- Review and update the release notes.
+  Review and update the `Changelog` file.
+  Get a partial list of contributors with something like::
+
+      git shortlog -ns 0.6.0..
+
+  where `0.6.0` was the last release tag name.
+
+  Then manually go over `git shortlog 0.6.0..` to make sure the release notes
+  are as complete as possible and that every contributor was recognized.
+
+- Use the opportunity to update the `.mailmap` file if there are any
+  duplicate authors listed from `git shortlog -ns`.
+
+- Add any new authors to the `AUTHORS` file. Add any new entries to the `THANKS` file.
+
+- Check the copyright years in `LICENSE`
+
+- Make sure all tests are passing for the latest commit intended to be released.
+  The recommended way to do this is to make a PR for the release.
+  Once the PR is merged then the release is now ready.
+
+#### Doing the release
+
+You might want to make tag the release commit on your local machine, push to [PyPI](https://pypi.org/project/delocate), review, fix, rebase, until all is good.
+Then and only then do you push to upstream on github.
+
+- Make an annotated tag for the release with tag of form `0.6.0`::
+
+      git tag -a 0.6.0
+
+- Push the tag with something like `git push origin 0.6.0` and that tag will be automatically deployed to PyPI.
+
+- Check how everything looks on PyPI - the description, the packages.
+  If anything doesn't look right then yank the release and upload with the patch version incremented.
+
+- Announce to the mailing lists. With fear and trembling.