The Test Team helps manage testing and triage across the WordPress ecosystem. They focus on user testing of the editing experience and WordPress dashboard, replicating and documenting bug reports, and supporting a culture of review and triage across the project.
Please drop by any time in SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/ with questions or to help out.
July 2: Test Chat Meeting Facilitator: Volunteer Needed
July 2: Test Chat Meeting Recap Notes: Volunteer Needed
3. Announcements 📣
GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc.
https://wordpress.org/gutenberg/ 21.0 was released last week and is now ready to download.
#accessibility team is working on the documentation in the WP AccessibilityAccessibilityAccessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Team’s Handbook. Please take a moment to fill in this feedback form so that they know what you think is important to read.
@sirlouen noted that most people in the #core team appeared to be completely unaware of the Test team’s work. He pointed out that even though @oglekler had been running test tables for a long time, this contribution was not widely known.
@krupajnanda acknowledged the lack of awareness and clarified that this was one of the reasons she had raised several points during earlier discussions. However, she mentioned that due to time constraints, she had not received many answers.
@oglekler emphasised the need for a structured plan outlining the team’s activities and goals. She suggested we also needed a proper content plan and proposed checking with the Core Dev Blog team to determine what kind of testing-related content could be shared there. She highlighted that once such content was published, the team could request amplification for a broader reach.
@krupajnanda proposed creating a “Month in Test” summary, similar to our existing weekly updates but offering a higher-level overview. She also suggested:
Reporting on the number of tickets resolved,
Tracking the onboarding of new contributors,
Hosting monthly video meetings (e.g., on Zoom or Google Meet),
Documenting updates,
And continuing patch testing work, which SirLouen had already been involved in.
@sirlouen shared that the current testing activities during release parties often involved repetitive tasks that did not effectively uncover issues in new features. He stated that contributors often performed the same basic actions, which could easily be covered by automated E2E (End-to-End) tests. He added that resources could be used more wisely by focusing on deeper feature-specific testing.
He proposed that:
Ideal test cases could be documented in developer notes before release parties.
The BetaBetaA 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. Testing PluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. could be enhanced to provide contextual testing instructions.
The plugin could be improved to engage testers more effectively, taking inspiration from Apple TestFlight.
@oglekler agreed that they needed automation for routine tasks, but stressed that human testers brought creativity and unpredictability that machines could not replicate. She felt the release parties served a dual purpose; verifying package integrity and fostering community spirit, and should not be discarded.
@krupajnanda added that documentation already existed (such as Help Test Docs), which outlined testing steps. However, she agreed that testers should go beyond ticking off checklists and explore newly introduced features to ensure functionality.
@sirlouen clarified that his intention was not to eliminate release parties but to make them more effective by focusing efforts on meaningful testing. He suggested creating a bullet list of tasks typically performed during release parties to help define what could be automated and what required human input.
@oglekler remarked that while most testers were simply updating via plugins, some were doing more extensive work, like testing version upgrades. She acknowledged that parties still had value but agreed that more targeted testing should be encouraged.
@krupajnanda proposed shifting focus from triage to testing 6.8.2 tickets starting next week. @oglekler responded that she would review the tickets, or possibly @sirlouen would do so first.
@sirlouen added that most 6.8.2 tickets had likely already been tested, as they had been merged into trunk earlier. He said he would still monitor bug scrubs for any relevant tickets.
@krupajnanda concluded that they would assess whether any tickets required special attention; if not, they would continue with triage as usual.
Hello and welcome to another edition of Week in Test, the place where contributors of any skill level can find opportunities to contribute to WordPress through testing. You can find the Test Team in #core-test.
Calls for Testing can originate from any team, from themes to mobile apps to feature plugins. The following posts highlight features and releases that need special attention:
Here’s a roundup of active tickets that are ready for testing contributions.
Did you know that contributions with the Test Team are also a fantastic way to level up your WordPress knowledge and skill? Dive in to contribute, and gain coveted props 😎 for a coming release.
Reproduction Testing 🔁
Who? Any contributor. Why? It is helpful to show an issue exists for other users in order to move a ticket forward for patching.
The following new tickets are awaiting review, and need testers to attempt to reproduce the reported issue (aka “repro”), and then provide a reproduction test report with the results:
Who? All contributors (not just developers) who can set up a local testing environment. Why? It is necessary to apply proposed patches and test per the testing instructions in order to validate that a patch fixes the issue.
The following tickets have been reviewed and a patch provided, and need testers to apply the patch and manually test, then provide feedback through a patch test report:
Who? Any QA or PHPPHPPHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/index.php developer contributors who can (or are interested in learning how to) build automated PHPUnit tests. Why?Automated tests improve the software development feedback loopLoopThe Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop for quality and backward compatibility.
This week’s note-taker is – Looking for a volunteer
Announcements
GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc.
https://wordpress.org/gutenberg/ 21.0 was released last week and is now ready to download.
#accessibility team is working on the documentation in the WP AccessibilityAccessibilityAccessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Team’s Handbook. Please take a moment to fill in this feedback form so that they know what you think is important to read.
Hello and welcome to another edition of Week in Test, the place where contributors of any skill level can find opportunities to contribute to WordPress through testing. You can find the Test Team in #core-test.
Here’s a roundup of active tickets that are ready for testing contributions.
Did you know that contributions with the Test Team are also a fantastic way to level up your WordPress knowledge and skill? Dive in to contribute, and gain coveted props 😎 for a coming release.
Reproduction Testing 🔁
Who? Any contributor. Why? It is helpful to show an issue exists for other users in order to move a ticket forward for patching.
The following new tickets are awaiting review, and need testers to attempt to reproduce the reported issue (aka “repro”), and then provide a reproduction test report with the results:
Who? All contributors (not just developers) who can set up a local testing environment. Why? It is necessary to apply proposed patches and test per the testing instructions in order to validate that a patch fixes the issue.
The following tickets have been reviewed and a patch provided, and need testers to apply the patch and manually test, then provide feedback through a patch test report:
Who? Any QA or PHPPHPPHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/index.php developer contributors who can (or are interested in learning how to) build automated PHPUnit tests. Why?Automated tests improve the software development feedback loopLoopThe Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop for quality and backward compatibility.
GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc.
https://wordpress.org/gutenberg/ 21.0 was released last week and is now ready to download.
The Performance team has announced that the initial release of the View Transitions pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. is now live on WordPress.orgWordPress.orgThe community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/. For more information about this plugin, please check the here.
WordPress Playground Update : Developers can now pass data URLs directly in the blueprint-url query parameter.
The CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Team is putting together a squad for future minor releases. A release squad for 6.8.2 and 6.8.3 will be announced soon. Follow #6-8-release-leads for updates.
Hello and welcome to another edition of Week in Test, the place where contributors of any skill level can find opportunities to contribute to WordPress through testing. You can find the Test Team in #core-test.
Calls for Testing can originate from any team, from themes to mobile apps to feature plugins. The following posts highlight features and releases that need special attention:
GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc.
https://wordpress.org/gutenberg/ 21.0 RCRelease CandidateA beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. is released and ready for testing. Please check this changelog for more information.
Here’s a roundup of active tickets that are ready for testing contributions.
Did you know that contributions with the Test Team are also a fantastic way to level up your WordPress knowledge and skill? Dive in to contribute, and gain coveted props 😎 for a coming release.
Reproduction Testing 🔁
Who? Any contributor. Why? It is helpful to show an issue exists for other users in order to move a ticket forward for patching.
The following new tickets are awaiting review, and need testers to attempt to reproduce the reported issue (aka “repro”), and then provide a reproduction test report with the results:
Who? All contributors (not just developers) who can set up a local testing environment. Why? It is necessary to apply proposed patches and test per the testing instructions in order to validate that a patch fixes the issue.
The following tickets have been reviewed and a patch provided, and need testers to apply the patch and manually test, then provide feedback through a patch test report:
Who? Any QA or PHPPHPPHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/index.php developer contributors who can (or are interested in learning how to) build automated PHPUnit tests. Why?Automated tests improve the software development feedback loopLoopThe Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop for quality and backward compatibility.
We are processing the badges to all the eligible contributors who participated and contributed on WCEU Contributors day. Thank you for your patience! 🙇♀️
AI Team has their first meeting and here here is the recap
The CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Team is working on a squad for future minor releases. A release squad for 6.8.2 should be announced soon. Follow #6-8-release-leads for updates.
It was an energising day of contribution and collaboration at WordCampWordCampWordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Europe 2025 Contributor DayContributor DayContributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/! The CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Test team gathered with purpose, passion, and curiosity; both online and in person; to move WordPress forward through testing.
Whether you helped test a patch, triaged a bug, or just explored how to get started, your time truly mattered. 🙌
We had a beautiful mix of contributors both seasoned testers and new faces:
44.4% contributed remotely
55.6% were there in person
And most exciting: 61.1% were first-time Core Test contributors!
Our contributors jumped into many testing activities across the WordPress project:
75% tested Core patches manually
37.5% helped triage issues
12.5% tested GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc.
https://wordpress.org/gutenberg/ PRs
A few explored unit testing or provided automation support
Others reviewed test instructions and helped folks get started!
💬 Community Voices
Here’s what some contributors shared:
“Table leads were super helpful and encouraging.”
“It was my first time and I felt welcomed.”
“@sirlouen explained things beautifully – big thanks!”
Many contributors asked for better docs and examples around E2E testing. We hear you and we will work on this part.
Special thanks to @sirlouen, who conducted two amazing onboarding sessions for new contributors! He helped so many people to take their first step into WordPress Core Testing. ✨
Big shout-out to the in-person Test Table Leads@oglekler and @boniu91 who actively engaged contributors, answered questions, and created a collaborative environment during Contributor Day. Your presence made a real difference! 🙌
🏅 Contributor Badges
Badges are in the process of being assigned to all eligible contributors. Thank you for your patience! Keep an eye on the upcoming weekly Test Team updates on make.wordpress.org/test for badge confirmations.
🗓️ Core-test Meetings
The Test Team meets every week in the #core-test channel on SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. Checkout the current meeting schedule and drop by whether to say hi, ask questions, or just lurk and learn!
Contributor Day is over, but your journey in the Test team doesn’t have to stop here. From exploring patches to writing your first test, we’re here to support you every step of the way. Check out the Test Handbook and stay tuned for more ways to contribute.
Thanks again for being part of the WordPress community! You made Contributor Day truly special. ✨
After intensive patch testing and reviewing 200+ tickets in the past few months from the Test Team perspective, I’ve found there is a gap between Testing and Committer delivery, and I’ve also found a possible solution. Here is the story:
Context
Let’s put a bug as an example for the current simplified flowFlowFlow is the path of screens and interactions taken to accomplish a task. It’s an experience vector. Flow is also a feeling. It’s being unselfconscious and in the zone. Flow is what happens when difficulties are removed and you are freed to pursue an activity without forming intentions. You just do it.-chart:
Current Working Workflow
Currently, there is a keyword dev-feedback that could be assigned after “Patch Testing Report”. Generally, dev-feedback is a great keyword to “pingPingThe act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.”” any committer that the report is ready for review and potentially “Ready to commit”.
But with this strategy, there is the following serious problem, that renders most Patch Testing Reports almost useless:
Most Patch Testers are not code reviewers. They only get some patch reproduction instructions, and they simply test the patch; they might not review the patch.
Most patches are not always the suitable solution, and they often need plenty of changes (if not a complete rework). For this reason, most committers simply ignore testing unless they know that the report comes from “trusted sources”. Trusted sources are members who have a reputation for good code reviewing.
For this reason, ultimately this establishes a full trust dynamic, rendering most Patch Testing Reports useless.
Moreover, there is another secondary problem: Reputed users cannot simply “Test Patches”: They should test and review the code to maintain a reputation.
Why simple Patch Testing (without Code Reviewing) is very useful?
Patch testing is just a negative-conditional process. This means that the purpose of Patch Testing is simply finding faulty patches and asking for changes (or refreshes). It helps triage and helps to filterFilterFilters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. down the queue of patches. Simple patch testing can be done efficiently and even by non-technical users.
Contrarily, Code Reviewing is very complex, and some degree of seniority is required.
After a negative Testing Report, new Action WF Keywords can be introduced like: changes-requested, or needs-refresh.
After a positive Testing Report as it’s currently designed, no Action WF Keyword could be introduced except for dev-feedback.
The problem
The concern is that currently there is no clear way for pinging “CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Developers” after a code-review apart from the dev-feedback keyword. In the handbook currently, it says:
A response is wanted from a core developer or trusted members of the development community. For example, use this keyword when double sign-off is required to backport changes during RCRelease CandidateA beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge.
Once a patch has been code-reviewed, the only way to proceed here is to use dev-feedback as a way to ping Committers like: “I attest that this report is ready to move forward”. But dev-feedback was not even meant for that. In fact, there is no specific keyword meant for this.
The current practice after code reviewing is not pinging at all or directly pinging your trusted committer.
But if you don’t have a trusted committer, and you would like that your code-review work doesn’t fade into oblivion, using dev-feedback this way (as it currently is), can potentially generate a “Trust-based dynamic” as commented in the beginning.
This will lead into 3 scenarios:
Non-technical Patch tester: Adds dev-feedback. The committer comes, sees that the patch tester is non-technical, and enters in the mood of “Time to review everything from scratch, I cannot trust anything of what I see”.
Technical Patch Tester: Add dev-feedback after a full Code Review. The committer comes with confidence and gives a second peer review to the patch. This patch can be committed with ease. Perfect scenario.
Technical Patch Tester: Add dev-feedback without a full Code Reviewer. The committer comes with some expectations (after all, it was written by a trusted reviewer), to discover that the patch is utterly useless. This will lower the reputation of the Technical Patch Tester because the Committer was expecting that a review should have been done.
This often leads committers to approach tickets with modest expectations, as they’re responsible for triaging these 3 scenarios, and this task can be quite demanding. As a result, many choose to start working from scratch to ensure accuracy and clarity. This behaviour is well understood, as it’s not uncommon to see committers echoing observations already noted in earlier reports. For example, comments like: “I have observed that this issue is happening because…” when there is a comment by another user saying exactly the same. This is an obvious symptom that some committers can ignore Test Reports because they know they have been historically untrustworthy.
The solution
There are two solutions:
The feeble: Commenting within the report that no review has been done. This can easily be overlooked if there is a lot of information within a report (lowering trust) plus this cannot be filtered in report listings.
The ideal: Creating a new Workflow Keyword called: needs-code-review.
Ideal Scenario for a Workflow
Following the 3 previous scenarios:
Non-technical Patch Tester: After testing, the needs-code-review will be set. Any Code reviewer will be able to filter this keyword and improve the quality of the report for the Committer.
Technical Patch Tester who does a full Code Review: They can directly jump into dev-feedback. Nothing changes here.
Technical Patch Tester who doesn’t want to do a full Code Review: Similar to the first scenario, needs-code-review will be set. Code review can be done afterwards, or leave the code review for another reviewer.
Advantages
Committers can prioritize, focusing on dev-feedback reports. During a bug-scrub, for example, it will be wiser to pick those first, and then continue with the rest. This will accelerate patch processing and reduce the burden of Committers of having to fully commit to reports from scratch.
Code Reviewers can prioritize needs-code-review tickets, to help committers.
This ensures double sign-offs on many tickets because non-committers can assist in the code review process, with this keyword serving as a useful entry point for reports.
Code Reviewing could be promoted as a very interesting activity during Contribution days for Core Team.
Committing and Patch Testing can be a completely detached process, as it should be (for the reasons stated above).
This approach can make it easier to promote and provide training on patch testing for non-technical users, allowing them to participate without needing to worry about code quality or best practices. Eventually, this could help facilitate batch patch testing more effectively.
Last but not least, Technical Patch Testers will not always be expected to perform a full code review. While this might seem like a minor benefit, it can significantly help the Core Test team by streamlining the triaging process.
Conclusion
The conclusion is that dev-feedback workflow keyword will be consistently used for what it was meant for:
Real Trust-based keyword for helping push commits (main use)
Backporting purposes like the commit double sign-offs during RC
Sometimes after a fixed-* backport (when backporter is the same as the committer)
Return to pinging the dev for administrative purposes
End note: This is part of the series “Improving the Keyword Workflow” which will be published soon. If you are willing to join the review, please contact me in #core-test or #core at SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/ @ SirLouen
You must be logged in to post a comment.