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.
We are in the last lap for the test handbook completion!
@sirlouen reported that he had already contacted the MetaMetaMeta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. team to schedule a date to start syncing and also mentioned that the project is 99.99% complete, and once a date is confirmed, they will complete the final administrative tasks and proceed. @sirlouen also noted that @dd32 was copied in on the communication.
@sirlouen also shared that he is going to edit all current documentation pages to add a GitHubGitHubGitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ link and indicate that the pages are outdated. Once the sync is complete, those pages will be removed and replaced with new content. He also mentioned that work can begin on one or two GitHub pages now, starting with the badges page.
@nikunj8866 emphasized that the slugs needs to be observed as same before removing and archiving old pages
A few Tickets were pending Reviews and volunteers were assigned. We are almost there. All tickets were reviewed by meetings end and merge ready. @sirlouen will proceed to merge
Proposal for creating an Archive Section in the Handbook. The archive section was supported in the last meeting and these two pages are among those to be first archived.
We need to build a new page for 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/testing @sirlouen is moving to Gutenberg tests and will do build the page
4. Open Floor
No additional topics were brought up during the open floor section of the meeting.
Call for Testing Several Issues are available for testing ahead of the 6.9 release. Let’s help collaborate on these as well. Here is a short list but more will surely be found especially after 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. release last night
Collaboration: add blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.-level comments:
We usually have 2 meetings held every week and the times have been listed bellow for next week. an adjustment has been made to include the WordPress 6.9 Test Scrub and will soon be listed
To facilitate the development and testing of the BlockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Commenting feature, @wildworks has created a plugin to bulk insert multiple block comments. Please feel free to use it if you need it.
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.7 is expected to be released today. Keep an eye here for the latest update.
Several existing issues have already been reported. See #71774
6. Focal Group Updates
@sirlouen has started building a dedicated 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 to replace the current one with plan to introduce new features along with a plan to redesign the Handbook sections for reports, which will be used for the new testing plugin for clarity. For more details please revisit meeting history here.
Badge Requirements
@sirlouen suggested increasing the minimum number of test reports from 1 to 5 tickets and proposed removing the requirements related to unit/e2e tests and contributing to WordPress test suites, as those are not directly related to the part of Test Team
8. Questions
@fakhriaz asked for recommendations on books, YouTube channels, and the best path to become an expert in testing and coding. @sirlouen suggested reading “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/preface.php.: The Right Way” for PHP, and checking the 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/ documentation and resources to learn about WordPress testing.
@krupajnanda mentioned everyone that the WordPress 6.9 release is coming soon, with 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. 1 expected in a month. They encouraged everyone to explore the new features, fixes, and enhancements, and to keep an eye on the roadmap and the “Week in Test” post for early testing opportunities.
@sirlouen mentioned that Contributors Onboarding & Coffee Hours session will be replaced with Patch Testing Scrubs, held after the weekly #core Live Bug Scrubs (Thursdays @ 1PM GMT).
6. Calls for Testers
Here are some tickets that need testing. This is a call for community testers to take them up whenever possible.
@oglekler suggested introducing tested a keyword in TracTracTrac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. so contributors can explicitly sign off with their name after testing a patch. This would add accountability and clarity to the testing process.
7.2 Current State of Testing
@sirlouen noted that testing is still happening somewhat at random, though it has improved compared to last year. He also pointed out there is no consistent or official testing protocol in CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress..
@oglekler agreed, saying that currently contributors just “rummage around” to find something to test.
7.3 Quality Assurance vs. Testing
@oglekler highlighted that the conversation should focus on Quality Assurance, not just testing. In commercial development, releases do not go live without QA approval, and this should become a WordPress standard.
7.4 Double-Test Enforcement
@sirlouen proposed enforcing a minimum of two independent tests before committing a patch, similar to the double sign-off required for RCRelease CandidateA beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. backports. He also admitted this may not be feasible right now due to limited testing resources.
7.5 Test Scrubs & Releases
@sirlouen suggested Test Scrubs could run side-by-side with bug scrubs during releases.
@krupajnanda explained that during release cycles, triage is often converted into a test scrub by targeting tickets scheduled for the upcoming version.
@sirlouen stressed that enforcing a “two-test” policy would make tickets nearly ready to commit once they are milestoned.
Appreciations to the 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://2017.us.wordcamp.org/contributor-day/https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/. Table Leads 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. US 2025 especially the Remote Leads.
Follow up on the proposal for the TracTracTrac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. Test Reports.
6.1 Change of the time for the Contributor Session – Sessions have been moved 1 hour ahead and this change has been updated in the meeting calendar. Next meeting will be on Thursday at 2PM GMT instead of the regular Thursday at 1PM GMT
6.2 Ticket Review Discussion
The team did not have time to fully review the ticket reports; this topic will continue next week.
There was some uncertainty expressed about the Needs Reproduction report — specifically, how it should be presented and structured.
Concern was raised about applying the Future Milestone tag too early, as it may feel premature in some cases.
Clarification:
Future Milestone is only for tickets that are already confirmed as valid and worth pursuing.
Ideally, one committer or maintainer should check in on a ticket before it gets this tag.
Currently, there is no alternative tag besides Future Milestone that signals such validation.
6.3 Meeting Notes – Permissions & Moderation
Request: @SirLouen suggested asking for more permissions on the Test P2P2P2 or O2 is the term people use to refer to the Make WordPress blog. It can be found at https://make.wordpress.org/. (for himself, @krupajnanda, and possibly @oglekler) to help moderate comments to avoid possible spam comment. (This is based on the recent observation on this post)
Agreement: @krupajnanda noted this is much needed and will check with #meta.
The Vote: voting was concluded with 7 votes in favour and 0 votes against as evidenced here
7. Open Floor
No additional topics were brought up during the open floor section of the meeting.
@sirlouen gave an update on the WordPress 6.8.2 Maintenance Release, specifically noting that the final quality review is still in progress and additional reviewers are welcome. He acknowledged that the review is taking a bit longer than expected due to the volume of data being processed. When @krupajnanda asked about the scope of the quality review, he clarified that it involves analyzing detailed test results and tables he previously shared in an earlier round table(RT) meeting.
In support of this effort, SirLouen also referred to the “A Month in Core – June 2025” update, showcasing contribution data. He highlighted concerns between the efforts of the Test Team in coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. contributions. This gap, backed by real data, will be further explored to help guide improvement and collaboration across teams.
@sirlouen also shared that he is planning to have zoom call with fellow contributors on the PHPStan proposal on this Friday, July 18 at 1 PM GMT / 3 PM CET / 6:30 PM IST. The goal of this call is to walk interested contributors through the current proposal, explore how they can get involved, and discuss some of the early feedback and ideas. This session will be conducted over a Zoom. @krupajnanda has requested to prepare the agenda and summary(after the meeting) post for the same.
During the discussion, we emphasized the importance of transparency and structure for any upcoming contributor focused calls. @krupajnanda suggested creating an agenda or call-out post similar to how team chats are managed. So contributors clearly understand the purpose, the topics to be covered, and who the call is aimed at (e.g., developers, QA, etc.). This would help set expectations, offer clarity, and encourage meaningful participation.
@krupajnanda mentioned that this approach would help us stay on track during meetings and @oglekler also acknowledged that if we doing anything within the community space then it should be done in community-friendly and transparent way.
The old testing queue has been mostly cleared, with only a few new tickets currently available for assignment: Testing Queue – WP Trac Query.
A roundtable meeting for contributor activity discussion. The goal is to analyze personal contribution decisions and encourage insight sharing across the team. (By the time I am posting this update, it is already done)
@krupajnanda requested @sirlouen to consider sharing a meeting agenda and summary post for the roundtable.
@sirlouen responded that while the meeting is meant to be informal and focus group–style, documentation might be considered after a few sessions.
@oglekler and @krupajnanda reminded that the Code of Conduct applies even in casual settings.
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.
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://2017.us.wordcamp.org/contributor-day/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
The next major releaseMajor ReleaseA set of releases or versions having the same major version number may be collectively referred to as “X.Y” -- for example version 5.2.x to refer to versions 5.2, 5.2.1, and all other versions in the 5.2. (five dot two dot) branch of that software. Major Releases often are the introduction of new major features and functionality. things are in progress and can be found here.
WCEU is around the corner. Please check out the schedule.
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/ 20.9 is scheduled for release on Wednesday, May 28, 2025.
Test team table lead for WCEU Contributor day @OGlekler will leading the Table for test team at WCEU. @Puja and @SirLouen will be our online leads. We will soon publish a post mentioning all the information about what and how contributors can help us at WCEU contributor table.
4. Test Team Updates
Week in Test Post: Wondering where you can contribute and learn? The Test Team’s got you covered.
No Questions/Blockers were reported in this meeting
7. Call for Testers/Visibility
#core-editor team has shared this issues that needs testing. Please feel free to pick and contribute to any tickets and make sure to update the same in the #core-editor for the better visibility.
8. Open Floor
The conversation focused on improving the testing workflow and coordination during Contributor Days, especially regarding ticket handling and visibility of test efforts.
@sirlouen raised concerns about the difficulty of enforcing test tag management purely through control, suggesting that clear contributor instructions might be more effective.
@krupajnanda supported the idea that contributors should ensure tickets with sufficient test reports no longer carry the “needs-testing” keyword and encouraged proactive keyword checks before picking tickets.
@oglekler proposed better planning for future Contributors Day, highlighting interesting or challenging tickets to attract attention.
The team agreed on the need for more strategic planning and gradual improvements. @krupajnanda offered to draft a Contributor Day post, incorporating curated tickets with specific keywords, to guide contributors more effectively.
The idea of showcasing handpicked tickets was welcomed to engage contributors and highlight meaningful work..
Are you interested in helping write Test chat summaries like this one? Volunteer at the start of the next <test-chat> and earn some props!Thank you @krupajnanda, for the peer review and for helping me write this post.
You must be logged in to post a comment.