diff --git a/.github/release-pull-request-template.md b/.github/release-pull-request-template.md
index f806222f5..4b1cd9fb7 100644
--- a/.github/release-pull-request-template.md
+++ b/.github/release-pull-request-template.md
@@ -10,6 +10,7 @@
 - [ ] Update this pull request's status from `draft` to `ready to merge`.
 - [ ] Review: Do a review of the commit to the `stable` branch to ensure the contents of the diffs are as expected.
 - [ ] Test: Check out the `stable` branch and test it locally to ensure everything works as expected.  It is recommended that you rename the existing `distributor` directory and check out `stable` fresh because switching branches does not delete files.  This can be done with `git clone --single-branch --branch stable git@github.com:10up/distributor.git`
+- [ ] Either perform a regression testing utilizing the available [Critical Flows](https://10up.github.io/Open-Source-Best-Practices/testing/#critical-flows) and Test Cases or if [end-to-end tests](https://10up.github.io/Open-Source-Best-Practices/testing/#e2e-testing) cover a significant portion of those Critical Flows then run e2e tests.  Only proceed if everything tests successfully.
 - [ ] Release: Create a [new release](https://github.com/10up/distributor/releases/new), naming the tag and the release with the new version number, and **targeting the `stable` branch**.  Paste the changelog from `CHANGELOG.md` into the body of the release and include a link to the [closed issues on the milestone](https://github.com/10up/distributor/milestone/#?closed=1).  The release should now appear under [releases](https://github.com/10up/distributor/releases).
 - [ ] Check release: Wait for the [Publish Release Action](https://github.com/10up/distributor/actions?query=workflow%3A%22Publish+Release%22) to complete, and then check the latest release to ensure that the ZIP has been attached as an asset.  Download the ZIP and inspect the contents to be sure they match the contents of the `stable` branch.
 - [ ] Close milestone: Edit the [milestone](https://github.com/10up/distributor/milestone/#) with release date (in the `Due date (optional)` field) and link to GitHub release (in the `Description` field), then close the milestone.
diff --git a/.github/workflows/cypress.yml b/.github/workflows/cypress.yml
index 806f5445f..65ef3ed29 100644
--- a/.github/workflows/cypress.yml
+++ b/.github/workflows/cypress.yml
@@ -108,7 +108,7 @@ jobs:
           npx mochawesome-report-generator tests/cypress/reports/mochawesome.json -o tests/cypress/reports/
           cat ./tests/cypress/reports/mochawesome.md >> $GITHUB_STEP_SUMMARY
     - name: Make artifacts available
-      uses: actions/upload-artifact@v3
+      uses: actions/upload-artifact@v4
       if: failure()
       with:
         name: cypress-artifact
diff --git a/.github/workflows/generate-zip.yml b/.github/workflows/generate-zip.yml
index da116934d..eb8c6c091 100644
--- a/.github/workflows/generate-zip.yml
+++ b/.github/workflows/generate-zip.yml
@@ -42,7 +42,7 @@ jobs:
           rm -rf ./release && unzip ${{ github.event.repository.name }}.zip -d ./release
 
       - name: Upload the ZIP file as an artifact
-        uses: actions/upload-artifact@v3
+        uses: actions/upload-artifact@v4
         with:
           name: ${{ github.event.repository.name }}
           path: release
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index d0e76b3f0..406384c47 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -22,6 +22,10 @@ Pull requests represent a proposed solution to a specified problem. They should
 
 For more on how 10up writes and manages code, check out our [10up Engineering Best Practices](https://10up.github.io/Engineering-Best-Practices/).
 
+### Testing
+
+Helping to test an open source project and provide feedback on success or failure of those tests is also a helpful contribution.  You can find details on the Critical Flows and Test Cases in [this project's GitHub Wiki](https://github.com/10up/distributor/wiki/Critical-Flows) as well as details on our overall approach to [Critical Flows and Test Cases in our Open Source Best Practices](https://10up.github.io/Open-Source-Best-Practices/testing/#critial-flows).  Submitting the results of testing via our Critical Flows as a comment on a Pull Request of a specific feature or as an Issue when testing the entire project is the best approach for providing testing results.
+
 ## Workflow
 
 The `develop` branch is the development branch which means it contains the next version to be released. `stable` contains the current latest release and `trunk` contains the corresponding stable development version. Always work on the `develop` branch and open up PRs against `develop`.