Proof of concept for test-handbook #184, built by @softglaze. The real TestFlow Console running as a static demo. Slack is simulated here so the Send buttons work, but nothing is actually posted. Everything else runs in your browser.
Session tools for WordPress Test Team moderators. The Test Team covers the whole ecosystem, not just core, so this console handles core Trac tickets, Gutenberg issues, meta and themes side by side.
Sessionchecking
Participants0
Tickets in the pool0
Slackchecking
History0assignments recorded, all sessions
Patch Testing Scrub
The session console. Timer, message templates with one-click send to Slack, a participant tracker with experience levels, ticket assignment with repeat detection, props, and an assignment history that survives across sessions.
The weekly team chat. Agenda, attendance, meeting notes, discussions, open floor, announcements and closing, with the facilitator and note-taker filled into every template.
The document a team lead asks for before your first session. Builds itself from the ticket pool and the message templates, and exports ready to paste into a Google Doc.
Everything currently in the pool, grouped by where it came from: core Trac, meta, themes and Gutenberg each get their own table with their own columns. Shows who has been handed each ticket, in this session and every earlier one.
If you have never run one of these, this is the whole path. Nothing here needs commit access or any special permission on wordpress.org.
Ask to run one, or offer to helpSay hello in #core-test on the Make WordPress Slack and say you would like to help with patch testing. Somebody will point you at the next session. If you want to moderate, say that too, and a team lead will usually ask you to write a plan first.
Get a test site you can breakWordPress Playground runs in a browser tab and needs nothing installed. The Contributor Toolkit sets up a full wordpress-develop environment if you would rather work locally. Either is fine, and neither touches this site.
Connect SlackOn the Patch Testing Scrub screen, save a bot token, paste the channel URL, and invite the app to the channel. The checklist above says which of those are done. Without a token the console can still send through a webhook, but it cannot read the channel, so it cannot pull participants.
Fill the ticket poolExport a Trac query as CSV and paste it in, or sync Gutenberg issues straight from GitHub, or type ticket ids by hand. Set a difficulty on each one, because that is what stops a beginner being handed something hard.
Write the plan and send itThe Scrub Plan screen turns the pool into the document a lead expects: the messages you will use, the tickets by tier, what you dropped and why, and how you will run the room. Export it, paste it into a doc, and send the link.
Run the sessionPress Start, which also sets the window for pulling participants. Send the opening messages, pull whoever replied, assign a ticket each, and acknowledge reports as they arrive. One ticket per person at a time.
Close it and give propsSend the closing messages, then the props message, which is built from the people who actually took part rather than everyone in the room. Keep an eye on the thread afterwards, because people finish late.
Each item is read from this browser and from the site every time this page loads. Anything unticked is not set up yet.
A Slack bot token is saved, so the console can read the channel and post
A channel link is pasted, so it knows where to send
The app has been invited to that channel with /invite
Tickets are in the pool, from a Trac CSV, a GitHub sync or typed in by hand
Tickets carry a difficulty, so beginners are not handed the hard ones
The timer is started, which is also what sets the window for pulling participants
The invite step cannot be checked from here. Slack only reports it when a read or a send fails, so treat that one as a reminder.
Run it in the channel you want the console to read and post in. Adding the app through Integrations adds the webhook, not the bot, so the slash command is still needed.
What a tester needs to know
From the handbook page on patch testing. Copy it into the channel when somebody new turns up.
The loop
Set up a test site. WordPress Playground is the fastest route and needs nothing installed.
Apply the patch, through Playground or through Grunt on a local build.
Run the reproduction steps on the ticket.
Check whether the patch fixes the problem, and whether it breaks anything else. A patch that fixes one thing and breaks another is a regression, and saying so is as useful as saying it works.
Post the report back on the ticket, and drop a note in the channel so the moderator can hand you another.
What goes in a report
Environment: WordPress version, PHP version, server, database, browser and OS, plus the active theme and every active plugin including must-use plugins.
Steps taken: what you actually did, in order, so somebody else can repeat it.
Expected result: what should have happened.
Actual result: what did happen, ending in a pass or fail mark.
Screenshots or a screencast, before and after the patch.
Additional notes: anything else that would help the committer.
The Test Reports plugin fills in the whole environment block for you and formats the report for Trac or for GitHub. Recommending it to a first-timer saves a lot of back and forth.
WordPress Contributor Toolkit 1.0 new
Announced on 14 August 2026. A desktop app that walks a first-time contributor through setting up a full wordpress-develop environment. It bundles Git, Node.js and npm, so nobody has to install those separately before they can test anything.
For a scrub it removes the step that loses people. Link a Trac ticket and it shows the ticket, its pull requests and its patches, applies the work, and runs it on a live site. Each linked ticket gets its own branch, so one environment covers a whole session. Finished work goes out as a GitHub pull request, an attachment on the ticket, or a patch handed to a mentor.
Builds exist for Windows, macOS on Apple Silicon, and Linux. Worth sending to anyone who says they would like to help but cannot get a local install working.
Every ticket and every participant carries a level: beginner, moderate or advanced. Assignment dropdowns sort matching tickets to the top and grey out the rest, but never block you, because the moderator in the room knows more than a keyword does.
Levels are read from labels where labels exist. On Trac, good-first-bug means beginner and has-test-info means moderate. On GitHub, Good First Issue means beginner, and a bug that also asks for testing means moderate. Anything the console cannot read is called advanced on purpose: handing a hard ticket to a beginner costs more than holding an easy one back.
What this console cannot do
It cannot read Trac. Trac refuses requests from servers, so ticket detail arrives only through a CSV you export in your own browser, or from GitHub, which does answer. Tickets typed in by hand carry no detail.
It cannot tell you whether someone tested a ticket outside this console. The repeat check is built from what this plugin assigned, in this browser.
It posts as the Slack app, not as you, unless you install it with a user token. The app has to be invited to a channel before it can read or post there.
Session state lives in this browser. A different machine, or a cleared browser, starts empty. Your Slack credentials are the exception: those are stored on the site.