remove mention of perf testing

docs/contributors/code/release.md

@@ -17,7 +17,7 @@ We release a new major version approximately every two weeks. The current and ne
 
 -   **On the date of the current milestone**, we publish a release candidate and make it available for plugin authors and users to test. If any regressions are found with a release candidate, a new one can be published. On this date, all remaining PRs on the milestone are moved automatically to the next release. Release candidates should be versioned incrementally, starting with `-rc.1`, then `-rc.2`, and so on. [Preparation of the release post starts here](/docs/block-editor/contributors/code/release/#writing-the-release-notes-and-post) and spans until the final release.
 
--   **One week after the first release candidate**, the stable version is created based on the last release candidate and any necessary regression fixes. Once the stable version is released, the release post is published, including a [performance audit](/docs/block-editor/contributors/testing-overview/#performance-testing).
+-   **One week after the first release candidate**, the stable version is created based on the last release candidate and any necessary regression fixes. Once the stable version is released and the release post is published.  
 
 If critical bugs are discovered on stable versions of the plugin, patch versions can be released at any time.
 
@@ -103,8 +103,7 @@ Documenting the release is a group effort between the release manager, Gutenberg
 1. Curating the changelog - Wednesday after the RC release to Friday
 2. Selecting the release highlights - Friday to Monday
 3. Drafting the release post - Monday to Wednesday
-4. Running the performance tests - Wednesday right after the stable release
-5. Publishing the post - Wednesday after stable release
+4. Publishing the post - Wednesday after stable release
 
 #### 1. Curating the changelog
 
@@ -140,21 +139,6 @@ When possible, the highlighted changes in the release post should include an ani
 
 These visual assets should maintain consistency with previous release posts; using lean, white themes helps in this regard and visually integrate well with the [make.wordpress.org/core](https://make.wordpress.org/core/) blog aesthetics. Including copyrighted material should be avoided, and browser plugins that can be seen in the browser canvas (spell checkers, form fillers, etc.) disabled when capturing the assets.
 
-#### 4. Running the performance tests
-
-The post should also include a performance audit at the end, comparing the current Gutenberg release with both the previous one and the latest WordPress major version. There are GitHub worfklows in place to do this comparison as part of the Continuous Integration setup, so the performance audit results can be found at the workflow run generated by the release commit in the [Performance Tests workflows](https://github.com/WordPress/gutenberg/actions/workflows/performance.yml) page, with the job name `Compare performance with current WordPress Core and previous Gutenberg versions`.
-
-If the GitHub workflow fails, the performance audit can be executed locally using `bin/plugin/cli.js perf` and passing the branches to run the performance suite against as parameters. In addition, the current major WP version can be passed to avoid running tests against the WP `trunk`. Example:
-
-```
-node ./bin/plugin/cli.js perf release/x.y release/x.z wp/a.b --wp-version wp.major
-```
-
-The performance values usually displayed in the release post are:
-
--   Time to the first block (test named `firstBlock`)
--   KeyPress Event (typing) (test named `type`)
-
 #### 5. Publishing the post
 
 Once the post content is ready, an author already having permissions to post in [make.wordpress.org/core](https://make.wordpress.org/core/) will create a new draft and import the content; this post should be published after the actual release, helping external media to echo and amplify the release news. Remember asking for peer review is encouraged by the [make/core posting guidelines](https://make.wordpress.org/core/handbook/best-practices/post-comment-guidelines/#peer-review)!
@@ -165,7 +149,7 @@ Occasionally it's necessary to create a minor release (i.e. X.Y.**Z**) of the Pl
 
 As you proceed with the following process, it's worth bearing in mind that such minor releases are not created as branches in their own right (e.g. `release/12.5.0`) but are simply [tags](https://github.com/WordPress/gutenberg/releases/tag/v12.5.1).
 
-The method for minor releases is nearly identical to the main Plugin release process (see above) but has some notable exceptions. Please make sure to read _the whole_ of this guide before proceeding.
+The method for minor releases is nearly identical to the main Plugin release process (see above) but has some notable exceptions. Please make sure to read _the entire_ guide before proceeding.
 
 #### Updating the release branch
 
@@ -217,7 +201,7 @@ This is expected. The draft release will contain only the plugin zip. Only once
 
 > Do I need to publish point releases to WordPress.org?
 
-Yes. The method for this is identical to the main Plugin release process. You will need a Gutenberg Core team member to approve the release workflow.
+Yes. The method for this is identical to the main Plugin release process. You will need a member of the Gutenberg Core team the Gutenberg Release team to approve the release workflow.
 
 > The release process failed to cherry-pick version bump commit to the trunk branch.