Merge pull request #97 from 10up/psorensen-patch-1

_includes/markdown/Releasing.md

@@ -41,7 +41,7 @@ In addition, ensure a ["Dependency Review" GitHub Action](https://github.com/10u
 
 <h2 id="release-process" class="anchor-heading">Release Process {% include Util/link_anchor anchor="release-process" %} {% include Util/top %}</h2>
 
-All releases should follow one of two [release processes we’ve crafted](https://github.com/10up/.github/blob/trunk/CONTRIBUTING.md#release-instructions) (i.e., when releasing a plugin to WordPress.org with [Ads.txt](https://github.com/10up/ads-txt/blob/develop/CONTRIBUTING.md#release-instructions) as an example, when not releasing a plugin to WordPress.org with [Distributor](https://github.com/10up/distributor/blob/develop/CONTRIBUTING.md#release-instructions)as an example) or even more simply, leverage a GitHub Action to automate the release and deploy to WordPress.org as necessary.  If this is a major release, we should consider publishing an update post on 10up.com/blog, related social sites, and updating any related microsites.  All WordPress plugin-related projects should utilize our [GitHub Action to deploy releases to WordPress.org](https://github.com/10up/action-wordpress-plugin-deploy) as well as our [GitHub Action to deploy readme and asset updates to WordPress.org](https://github.com/10up/action-wordpress-plugin-asset-update) (e.g., bumping the WordPress `Tested up to` value, updating screenshots).  Both of these actions help automate the integration and management of WordPress.org's SVN-based repository, help eliminate human erros from working with SVN, and keep our released assets on WordPress.org a bit more secure (as access to SVN is gated by a bot account that the GitHub Action has access to via GitHub organization secrets).
+All releases should follow one of two [release processes we’ve crafted](https://github.com/10up/.github/blob/trunk/CONTRIBUTING.md#release-instructions) (i.e., when releasing a plugin to WordPress.org with [Ads.txt](https://github.com/10up/ads-txt/blob/develop/CONTRIBUTING.md#release-instructions) as an example, when not releasing a plugin to WordPress.org with [Distributor](https://github.com/10up/distributor/blob/develop/CONTRIBUTING.md#release-instructions)as an example) or even more simply, leverage a GitHub Action to automate the release and deploy to WordPress.org as necessary.  If this is a major release, we should consider publishing an update post on 10up.com/blog, related social sites, and updating any related microsites.  All WordPress plugin-related projects should utilize our [GitHub Action to deploy releases to WordPress.org](https://github.com/10up/action-wordpress-plugin-deploy) as well as our [GitHub Action to deploy readme and asset updates to WordPress.org](https://github.com/10up/action-wordpress-plugin-asset-update) (e.g., bumping the WordPress `Tested up to` value, updating screenshots).  Both of these actions help automate the integration and management of WordPress.org's SVN-based repository, help eliminate human errors from working with SVN, and keep our released assets on WordPress.org a bit more secure (as access to SVN is gated by a bot account that the GitHub Action has access to via GitHub organization secrets).
 
 Once a release has been tagged on GitHub, include the link to the release tag in the related milestone, ensure the milestone date is accurate, move any remaining open issues or PRs from the milestone to a future milestone, remove any closed but unmerged PRs from the milestone, and then close the milestone.