Chore(#127): add dev guidelines

.github/ISSUE_TEMPLATE/blank_issue.yml

@@ -0,0 +1,17 @@
+name: Blank issue
+description: Create a new issue from scratch
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thank you for contributing an issue to our project!
+  - type: markdown
+    attributes:
+      value: |
+        If you are reporting a bug or requesting a feature, please click "Choose a different template" above.
+  - type: textarea
+    id: description
+    attributes:
+      label: Description
+    validations:
+      required: true

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -2,7 +2,6 @@ name: Bug report
 description: Use this template to report bugs
 title: "[Bug Report]:"
 labels: "bug"
-assignees: "andybeet"
 body:
   - type: markdown
     attributes:

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1 @@
+blank_issues_enabled: false

.github/ISSUE_TEMPLATE/data_issues.yml

@@ -2,7 +2,6 @@ name: Data Issues
 description: Missing, Incorrect, Duplicate data?
 title: "[Data]: "
 labels: "data"
-assignees: "andybeet"
 body:
   - type: markdown
     attributes:

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -2,7 +2,6 @@ name: Feature Request
 description: Suggest an idea to help us improve
 title: "[Feature]: "
 labels: "feature"
-assignees: "andybeet"
 body:
   - type: markdown
     attributes:

.github/PULL_REQUEST_TEMPLATE/dev_pr.md

@@ -0,0 +1,25 @@
+PRs into `dev` contained all necessary info. They have already been approved.
+Please provide the information below so `main` can be synced with `dev`:
+
+### List PRs
+
+List the PRs that were merged into `dev` that will be pulled into `main` and any issues they fix:
+
+* PR #? which fixes #?
+
+### Types of changes
+
+What types of changes does this pull request introduce? Put an `x` in the boxes that apply.
+This will inform the new release number.
+
+- [ ] Fix (non-breaking change which fixes a bug)
+- [ ] Feature (non-breaking change which adds or changes functionality)
+- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
+- [ ] Other change (if none of the other choices apply)
+
+### Reviewer instructions
+
+The underlying PRs should have been reviewed. Please check that the proposed merge is correct before approving.
+If any checkboxes other than "Other change" have been selected please prepare the following file changes for a new release version:
+- [ ] NEWS.md - add release notes
+- [ ] DESCRIPTION - increment the version number according to [Semantic Versioning](https://semver.org)

.github/pull_request_template.md

@@ -0,0 +1,36 @@
+Your commits explain the `who`, `what`, `where` and `when` of these changes. Your code shows the `how`. You do not need to reiterate this. This PR should complete the picture by explaining `why` these changes are necessary.
+Please complete the fields below, replacing or removing placeholder text where necessary:
+
+### Justification
+
+Please describe the importance/impact of the problem and a description of how the changes in this pull request will address, resolve or improve it. This section should sufficiently explain to reviewers why these changes should be approved.
+If the proposed changes should close an issue, be sure to link to it below:  
+Fixes #?
+
+### Types of changes
+
+What types of changes does this pull request introduce? Put an `x` in the boxes that apply.
+This will inform the new release number.
+
+- [ ] Fix (non-breaking change which fixes a bug)
+- [ ] Feature (non-breaking change which adds or changes functionality)
+- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
+- [ ] Other change (if none of the other choices apply)
+
+### Further comments
+
+If this is a relatively large or complex change, kick off a discussion by explaining why you chose the solution you did, what alternatives you considered, problems you may have encountered, etc.
+
+### Reviewer instructions
+
+Assign at least 2 reviewers: 
+* one of which should be a maintainer of this repo, 
+* the others should be familiar with the subject or problem.
+
+Please detail the process reviewers will need to follow to properly test these changes. It is especially helpful to identify the exact code needed to conduct a local build/review/test and to specify any aspects of the testing that may not be obvious.
+
+### Formatting
+
+This repo contains an `air.toml` file that automatically formats code to a set of standards.
+It is preferred that contributors and reviewers install the [Air](https://posit-dev.github.io/air/) formatting tool.
+Code submitted in this pull request will be automatically checked for correct formatting.

.github/workflows/format-check.yaml

@@ -0,0 +1,23 @@
+# Workflow derived from https://github.com/posit-dev/setup-air/tree/main/examples
+
+on:
+  push:
+    branches: [main, master]
+  pull_request:
+
+name: format-check.yaml
+
+permissions: read-all
+
+jobs:
+  format-check:
+    name: format-check
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v6
+
+      - name: Install
+        uses: posit-dev/setup-air@v1
+
+      - name: Check
+        run: air format . --check

.github/workflows/format-suggest.yaml

@@ -0,0 +1,46 @@
+# Workflow derived from https://github.com/posit-dev/setup-air/tree/main/examples
+
+on:
+  # Using `pull_request_target` over `pull_request` for elevated `GITHUB_TOKEN`
+  # privileges, otherwise we can't set `pull-requests: write` when the pull
+  # request comes from a fork, which is our main use case (external contributors).
+  #
+  # `pull_request_target` runs in the context of the target branch (`main`, usually),
+  # rather than in the context of the pull request like `pull_request` does. Due
+  # to this, we must explicitly checkout `ref: ${{ github.event.pull_request.head.sha }}`.
+  # This is typically frowned upon by GitHub, as it exposes you to potentially running
+  # untrusted code in a context where you have elevated privileges, but they explicitly
+  # call out the use case of reformatting and committing back / commenting on the PR
+  # as a situation that should be safe (because we aren't actually running the untrusted
+  # code, we are just treating it as passive data).
+  # https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/
+  pull_request_target:
+
+name: format-suggest.yaml
+
+jobs:
+  format-suggest:
+    name: format-suggest
+    runs-on: ubuntu-latest
+
+    permissions:
+      # Required to push suggestion comments to the PR
+      pull-requests: write
+
+    steps:
+      - uses: actions/checkout@v6
+        with:
+          ref: ${{ github.event.pull_request.head.sha }}
+
+      - name: Install
+        uses: posit-dev/setup-air@v1
+
+      - name: Format
+        run: air format .
+
+      - name: Suggest
+        uses: reviewdog/action-suggester@v1
+        with:
+          level: error
+          fail_level: error
+          tool_name: air

CODE_OF_CONDUCT.md

@@ -0,0 +1,68 @@
+# NOAA Fisheries Open Science Code of Conduct
+
+This code of conduct was developed and adapted from the Atom code of conduct in October 2021, 
+and revised from NOAA-NMFS-Brand-Resources in June 2024
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+ advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+ address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+ professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported 
+by contacting the project team. All complaints will be reviewed and investigated 
+and will result in a response that is deemed necessary and appropriate to the 
+circumstances. Further details of specific enforcement policies may be posted 
+separately.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org/), version 1.4,
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+