feat: add contribution guidelines (#25)

Author: gadomski

.github/pull_request_template.md

@@ -0,0 +1,14 @@
+<!-- pyml disable-next-line first-line-heading -->
+## What I'm changing
+
+- <!-- a list of changes, including any issues this might close or reference -->
+
+## How I did it
+
+- <!-- more detail on decisions and choices -->
+
+## Checklist
+
+- [ ] Tests pass: `uv run pytest`
+- [ ] Checks pass: `uv run pre-commit --all-files`
+- [ ] CHANGELOG is updated (if necessary)

CONTRIBUTING.md

@@ -0,0 +1,67 @@
+# Contributing
+
+First, thanks for contributing to **pystapi**!
+The [README](./README.md#development) as instructions on setting up your development environment, which is a great place to start.
+
+## Repository organization
+
+**pystapi** is a "monorepo", meaning that it contains several sub-projects.
+Each project has it's own `pyproject.toml` file, README, CHANGELOG, tests, and more.
+Development dependencies should be specified at the top-level `pyproject.toml` file, as tests are intended to be run for the entire repository at once.
+
+## Branches
+
+We have a single primary development branch, **main**.
+Releases are cut from this branch by tags.
+Tags are named to identify which project they are releasing, e.g. a **stapi-pydantic** tag might look like `stapi-pydantic/v0.1.2`.
+If necessary, long-lived release branches are used to manage non-breaking changes and fixes, e.g. a `stapi-pydantic/v0.1` branch to handle any bugfixes that need to be backported to the v0.1 lineage of the project after **main** has incorporated breaking changes.
+
+## Testing
+
+We use [pytest](https://docs.pytest.org).
+Tests should be written in the "pytest style", i.e. free functions.
+
+Good:
+
+```python
+def test_foo() -> None:
+    assert 1 == 1
+```
+
+Bad:
+
+```python
+class FooTest(unittest.TestCase):
+    def test_foo(self) -> None:
+        assert 1 == 1
+```
+
+## Static typing
+
+We use [mypy](https://mypy-lang.org/) for static typing.
+When possible, projects work in `strict` mode, meaning that type checking is strongly enforced.
+Some projects are not quite ready for `strict` mode, but we want to get them there.
+
+## Lints and checks
+
+We use [pre-commit](https://pre-commit.com/).
+If you want to run checks on every commit:
+
+```shell
+uv run pre-commit install
+```
+
+If you ever need to disable **pre-commit** when committing use `--no-verify`:
+
+```shell
+git commit --no-verify
+```
+
+## Submitting changes
+
+Open a [pull request](https://github.com/stapi-spec/pystapi/pulls) with your changes, and fill out the provided template.
+It's not required, but it's helpful if you name your pull request in the [Conventional Commit](https://www.conventionalcommits.org/en/v1.0.0/) style, as the pull request titles are the eventual commit title for your changes (we use squash-and-merge).
+A **pystapi** maintainer will review your PR and request any changes.
+Once approved, if you have the permissions you can merge your PR ... if you don't, a maintainer will.
+
+If your PR is not ready for review, but you'd like some feedback on it anyways, open it as a draft.

README.md

@@ -30,6 +30,8 @@ If you don't want to type `uv run` all the time:
 source .venv/bin/activate
 ```
 
+See our [contribution guidelines](./CONTRIBUTING.md) for information on contributing any changes, fixes, or features.
+
 ### stapi-fastapi server
 
 A minimal test implementation is provided in [stapi-fastapi/tests/application.py](stapi-fastapi/tests/application.py).

pyproject.toml

@@ -70,7 +70,7 @@ module = "pygeofilter.parsers.*"
 ignore_missing_imports = true
 
 [tool.pymarkdown]
-plugins.md013.line_length = 120
+plugins.md013.enabled = false  # @gadomski likes to do one-line-per-sentence in markdown
 plugins.md024.enabled = false  # duplicate headers in changelog
 
 [tool.coverage.report]