Since WordPress 6.2, every WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. release has had one or two Performance Leads as part of the WordPress Release Team Squad. This is a critical role to ensure that each release is on track to achieving or maintaining solid performance, and to highlight performance updates or concerns with the other members of the release squad.
Ideally, every WordPress Core release should have at least one Performance Lead. Any active member of the Core Performance Team can take on the role. It is encouraged that it is rotated between different members of the team for each release.
The Performance Lead role is scoped to a specific release and separate from the Core Performance Team RepTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. role. The Core Performance Team Reps do not need to be involved in WordPress release coordination and relevant tasks. However, they should help find a Performance Lead for every release, e.g. by asking for volunteers in the #core-performance channel on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. when relevant.
Responsibilities
The sections below outline specific responsibilities in a bit more detail.
Running benchmarks for the latest release
Once the first BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. of a WordPress Core release is available, the Performance Lead should run benchmarks to compare its performance to that of the previous stable release. At the very minimum, this should happen once before the actual release, e.g. using one of the release candidates (RCRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge.).
Drafting and publishing the performance improvements post for the latest release
Closer to the stable release, the Performance Lead should draft a “WordPress x.y performance improvements” post on the Make Core blog. This post should highlight the key performance improvements in the release, and it should also mention the benchmarks gathered for the release, including an assessment on what it means for WordPress Core’s performance (e.g. benefit? regression?).
The format of the post can vary. For reference, see the performance improvements posts for 6.7, 6.6, 6.5, 6.4, 6.3, and 6.2. Ideally the post starts with a mention of the “series” of similar posts and includes links to all prior ones. You can take over the copy from previous releases’ performance improvements posts.
Feel free to draft the post either in a Google doc or directly on the Make WordPress Core blog. If you do the latter, make sure you don’t accidentally hit “Publish” just yet!
Once you have completed a first draft, you can request feedback in the #core-performance channel on Slack. For a Google doc, you could grant public comment access. For a draft on Make WordPress Core, you could use the “Public Post Preview” feature.
Once you are happy with the draft, you should post it ideally a few days after the stable release has launched.
