Update CONTRIBUTING.md

CONTRIBUTING.md

@@ -42,8 +42,9 @@ The `develop` branch is the development branch which means it contains the next
 8. Push: Push your trunk branch to GitHub (e.g. `git push origin trunk`).
 9. [Compare](https://github.com/10up/restricted-site-access/compare/trunk...develop) `trunk` to `develop` to ensure no additional changes were missed.
 10. Test the pre-release ZIP locally by [downloading](https://github.com/10up/restricted-site-access/actions/workflows/build-release-zip.yml) it from the **Build release zip** action artifact and installing it locally. Ensure this zip has all the files we expect, that it installs and activates correctly and that all basic functionality is working.
-11. Release: Create a [new release](https://github.com/10up/restricted-site-access/releases/new), naming the tag and the release with the new version number, and targeting the `trunk` branch. Paste the changelog from `CHANGELOG.md` into the body of the release and include a link to the closed issues on the milestone (e.g. `https://github.com/10up/restricted-site-access/milestone/2?closed=1`). The release should now appear under [releases](https://github.com/10up/restricted-site-access/releases).
-12. SVN: Wait for the [GitHub Action](https://github.com/10up/restricted-site-access/actions) to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
-13. Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/restricted-site-access/. This may take a few minutes.
-14. Close milestone: Edit the [X.Y.Z milestone](https://github.com/10up/restricted-site-access/milestone/#) with release date (in the `Due date (optional)` field) and link to GitHub release (in the `Description` field), then close `X.Y.Z` milestone.
-15. Punt incomplete items: If any open issues or PRs which were milestoned for `X.Y.Z` do not make it into the release, update their milestone to `X.Y.Z+1`, `X.Y+1.0`, `X+1.0.0`, or `Future Release`.
+11. 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.
+12. Release: Create a [new release](https://github.com/10up/restricted-site-access/releases/new), naming the tag and the release with the new version number, and targeting the `trunk` branch. Paste the changelog from `CHANGELOG.md` into the body of the release and include a link to the closed issues on the milestone (e.g. `https://github.com/10up/restricted-site-access/milestone/2?closed=1`). The release should now appear under [releases](https://github.com/10up/restricted-site-access/releases).
+13. SVN: Wait for the [GitHub Action](https://github.com/10up/restricted-site-access/actions) to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
+14. Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/restricted-site-access/. This may take a few minutes.
+15. Close milestone: Edit the [X.Y.Z milestone](https://github.com/10up/restricted-site-access/milestone/#) with release date (in the `Due date (optional)` field) and link to GitHub release (in the `Description` field), then close `X.Y.Z` milestone.
+16. Punt incomplete items: If any open issues or PRs which were milestoned for `X.Y.Z` do not make it into the release, update their milestone to `X.Y.Z+1`, `X.Y+1.0`, `X+1.0.0`, or `Future Release`.