diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
new file mode 100644
index 0000000..0ec99cd
--- /dev/null
+++ b/.github/CODEOWNERS
@@ -0,0 +1,2 @@
+## Code changes will send a PR to the following users
+* @medley56
diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
new file mode 100644
index 0000000..c29ab76
--- /dev/null
+++ b/.github/pull_request_template.md
@@ -0,0 +1,12 @@
+# Title of PR
+
+Brief description of changes. If you write good commit messages, put the concatenated list of messages here.
+
+
+## Checklist
+- [ ] Changes are fully implemented without dangling issues or TODO items
+- [ ] Deprecated/superseded code is removed or marked with deprecation warning
+- [ ] Current dependencies have been properly specified and old dependencies removed
+- [ ] New code/functionality has accompanying tests and any old tests have been updated to match any new assumptions
+- [ ] The changelog.md has been updated
+- [ ] Code has been reviewed by a code owner and/or trusted contributor
diff --git a/.gitignore b/.gitignore
index 5a8e46f..e49e8cd 100644
--- a/.gitignore
+++ b/.gitignore
@@ -62,6 +62,7 @@ Thumbs.db
 # Virtual environment #
 #######################
 venv
+.venv
 
 # Configurations #
 ##################
diff --git a/docs/source/developers.md b/docs/source/developers.md
index 274302d..186c472 100644
--- a/docs/source/developers.md
+++ b/docs/source/developers.md
@@ -17,11 +17,19 @@ To run all tests in docker containers (tests against many versions of python), r
 docker-compose up --build && docker-compose down
 ```
 
+## Making a Pull Request
+Feel free to fork this repo and submit a PR! We do trunk-based development so all PRs should be destined for the
+`main` branch. Reviews are required before merging and our automated tests must pass. Please see the following
+checklist for a basic set of requirements before we will merge a PR.
+
+Please use the PR template when submitting a PR.
+
 ## Release Process
 Reference: [https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow)
 
 1. Create a release candidate branch named according to the version to be released. This branch is used to polish
-   the release while work continues on dev (towards the next release). The naming convention is `release/X.Y.Z`
+   the release but is fundamentally not different from any other feature branch in trunk-based development. 
+   The naming convention is `release/X.Y.Z`. 
 
 2. Bump the version of the package to the version you are about to release, either manually by editing `pyproject.toml`
    or by running `poetry version X.Y.Z` or bumping according to a valid bump rule like `poetry version minor`
@@ -31,12 +39,13 @@ Reference: [https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-
 
 4. Update `changelog.md` to reflect that the version is now "released" and revisit `README.md` to keep it up to date.
    
-5. Open a PR to merge the release branch into master. This informs the rest of the team how the release 
-   process is progressing as you polish the release branch.
+5. Open a PR to merge the release branch into main. This informs the rest of the team how the release 
+   process is progressing as you polish the release branch. You may need to rebase the release branch onto 
+   any recent changes to `main` and resolve any conflicts on a regular basis.
 
-6. When you are satisfied that the release branch is ready, merge the PR into `master`. 
+6. When you are satisfied that the release branch is ready, merge the PR into `main`. 
 
-7. Check out the `master` branch, pull the merged changes, and tag the newly created merge commit with the 
+7. Check out the `main` branch, pull the merged changes, and tag the newly created merge commit with the 
    desired version `X.Y.Z` and push the tag upstream. 
    
    ```bash
@@ -44,14 +53,11 @@ Reference: [https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-
    git push origin X.Y.Z
    ```
    
-8. Ensure that you have `master` checked out and build the package (see below).
+8. Ensure that you have `main` checked out and build the package (see below).
    Check that the version of the built artifacts is as you expect (should match the version git tag and the 
    output from `poetry version --short`).
    
 9. Optionally distribute the artifacts to PyPI/Nexus if desired (see below).
-   
-10. Open a PR to merge `master` back into `dev` so that any changes made during the release process are also captured
-    in `dev`. 
 
 
 ## Building and Distribution
@@ -59,4 +65,4 @@ Reference: [https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-
    
 2. To build the distribution archives, run `poetry build`.
    
-3. To upload the wheel to Nexus, run `poetry publish`. You will need credentials to sign into PyPI.
+3. To upload the wheel to Nexus, run `poetry publish`. You will need credentials to sign in to PyPI.