Disclaimer: This briefing was primarily generated using an AI tool from the video transcription.

Last 25th of July 2025, an informal meeting of the WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Testing Team, focusing on a proposed new workflow aimed at improving the quality and efficiency of bug resolution and patch delivery within the WordPress project. The discussion covered challenges with the current system, the rationale behind specializing in components, and a revised process for triaging, testing, reviewing, and committing tickets.

Key Themes and Most Important Ideas/Facts

1. The Problem: Wasted Effort and Lack of Confidence

The primary motivation for the new workflow stems from a significant amount of wasted effort in addressing tickets that are ultimately closed due to many unforeseen conflicts.

• High Rate of Unsolved Tickets Growth: Approximately 80% of the reports end either in a close or a position that will not receive a successful fix for a long time (if ever). This means considerable time and effort (sometimes multiple rounds of reproduction, patching and refreshing) are invested in tickets that are ultimately discarded.
• Lack of Confidence in Closing Tickets: Many contributors lack the “confidence to close tickets or proposing closing,” leading to continued work on unviable issues.
• Difficulty in Predicting Conflicts: The “hard complexity” of visualizing “what are all the elements that could be conflicting” early in the process leads to late-stage discovery of unsolvable problems.
• Broad Contributor Scope: Contributors currently “are working thorough the project at the same time,” most working across literally all the components. This prevents them from developing deep expertise in any single area and overlook the most important things with ease.

2. The Solution: Component Specialization and Enhanced Review

The proposed solution centres on encouraging contributors to specialize in specific WordPress components, fostering deep expertise that will enable more efficient and accurate triaging and review processes.

• Specialization to earn confidence: Specialization by selecting a single WordPress component because approaching the project as a whole might not be feasible for an individual.
• Mastering a Component: The goal for contributors in this group should be to master a just one component in an affordable time frame.

• Improved Review Process: Specialists will be able to read any report within their selected component and triage with confidence. This early identification of unviable tickets is crucial.

The ultimate purpose is to provide definitive patches, so the committers can trust to a degree that the last review is almost bureaucratic, being so confident that the ticket is the best possible that they wouldn’t have any doubt because they already know they are treating with a specialist in that component.

3. Proposed Workflow: A “Mini-Tracker” System

A modified workflow is proposed, utilizing a GitHubGitHub GitHub 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/ project board (a “mini-tracker”) to streamline the process for tickets handled by specialists, aiming to ensure higher quality controls over the period of implementation.

• New Ticket Triage by Specialist: A new report comes in (i.e., on “media”). A component specialist (i.e., “Prashant”) reads the report. Due to their expertise, they can quickly assess if it’s a problem that needs reproduction in a minimal amount of time.
• Needs Reproduction TagTag Tag is one of the pre-defined taxonomies in WordPress. Users can add tags to their WordPress posts along with categories. However, while a category may cover a broad range of topics, tags are smaller in scope and focused to specific topics. Think of them as keywords used for topics discussed in a particular post.: The specialist tags the ticket in TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. as needs-testing (or ideally generating a new tag called needs-reproduction that doesn’t exist nowadays) and then creates a corresponding entry on the GitHub project board with basic info (Trac ID, Trac URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org, component). This board acts as a filtered list of “super clear” tickets that have been reviewed by a specialist.
• Bug Reproduction by Tester: A tester (i.e., “Krupa”) picks a ticket from the “Needs Reproduction” column on the GitHub mini-tracker board, reproduces the bug, writes a report and tags it as needs-patch in Trac (or closes if it’s not valid). Then they move it to an “In progress” column on the GitHub board.
• Patch Development: Someone (within or outside the group) develops the patch. Periodically, someone within the team will be checking all the “In Progress” tickets in the mini-tracker to see if they already have a patch, and move it into the next step of the mini tracker, Needs Review.
• Patch Review by Specialist: The component specialist (e.g., “Prashant”) reviews the patch, suggesting modifications if needed They may tag it in Trac as changes-requested if modifications are needed, or needs-testing if code is adequate and could move into the next phase, Needs Patch Testing.
• Patch Testing by Tester: After the patch is modified and approved by the specialist, a tester (e.g., “Krupa”) tests the patch with the corresponding Patch Testing Report in Trac.
• Ready to Commit: Once tested and reviewed by specialists, the ticket is deemed “technically perfect and ready to be committed” minimizing the review burden on core committers.

Addressing a concern by @krupajnanda about “why having two places with the same testing information“, this “mini-track” ensures that tickets worked on by this group are those “that you know 100% that have been reviewed by a specialist,” contrasting with the “open sea of needs-testing tickets” in Trac where “anyone can put needs testing.”. We have to remember, that currently anyone that signs into Trac, can 1. Open a Ticket, 2. Add needs-testing tag at the same time as the ticket is opened. This is creating a massive inefficiency to the Test Team that has been more than proven. Anyway, testers can freely choose from either the Mini-Tracker or the Trac’s open sea, but we will encourage prioritizing first the Mini-Tracker ones for the reasons stated above.

4. Component Status Examples discussed in meeting

• Media: Second most opened tickets after “General.” Probably will require more than one contributor in this area.
• Posts (Post Types): Massive number of unanswered tickets due to lack of a current component maintainer.
• Editor: High number of tickets without answers (over 100), good option for active GutenbergGutenberg The 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/ contributors.
• TinyMCE: This type of component may be moving towards a “legacy situation” so, in the first stage, they are a not the best selection, and we should prioritize on the rest.
• Application Passwords, TaxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies.: Suggested as good starting points for those unsure, being affordable components.
• REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/.: Mentioned by @pmbaldha as a component of interest.
• Comments & Formatting: Mentioned by @yashjawale as components of interest for their smaller size.

5. Focus on Quality vs. Testing

The initiative emphasizes “improving the quality” of tickets, rather than just testing. It was clarified that we are not testing. The core test team’s name is acknowledged as potentially misleading, suggesting “Core Quality” might be more accurate.

6. Relationship with Component Maintainers

The new role of “reviewer” (component specialist) is closely aligned with the existing “component maintainer” role. The initiative aims to empower more contributors to ultimately become official component maintainers, addressing the current inactivity in many areas.

• Reviewing as a New Skill: The initiative aims to introduce “reviewing” as a skill within the test team.
• Path to Component Maintainership: The project serves as a “testing protocol” for contributors. It aims to address the perceived difficulty in becoming a component maintainer, as some contributors feel they need to “demonstrate your skills” before asking.

7. Concerns and Counterarguments

Jonathan (@desrosj), a committer, raised several concerns regarding the proposed workflow and underlying assumptions.

• Duplication of Work: “We’re duplicating a lot of the work here, and what I’m hearing is that Gutenberg and track is not either accurate enough or effective enough in helping you all find things to test.“
• Confusing for New Contributors: Introducing a separate project board is “confusing, especially for people that are newer to contributing,” as it adds complexity to where information should be added and tracked.
• “Wasted Effort” Redefined: Jonathan argues that efforts on tickets that are ultimately closed are “are not necessarily wasted, that’s good effort that we test things, and we find that they don’t work, or they’re not appropriate“.
• Committers Always Review: Jonathan refutes the idea that committers will eventually “just commit something that is tagged a certain way,” stating, “We’re always going to do our own review, our own research, our own testing.”
• Documentation of Component Maintainership: A significant takeaway from the discussion is the lack of documentation on “the expectations and the requirements and the path to become a component maintainership.” Jonathan committed to documenting this in the handbook.
• Focus on Improving Existing Tools: Jonathan suggests focusing on “why are the keywords not working, like how can we get better reports” within existing systems, rather than introducing new ones.

8. Pilot Program Mindset

@SirLouen emphasizes that this is an “informal”, “expiring proposal” and a “testing protocol,” not a permanent change.

• Not Set in Stone: “This is not something that will be forever”. Probably the original idea will change as we will be redefining through iterative improvement“.
• About Duplication: We have to remember that this is not going to replace Trac. Everything should be logged in Trac as mentioned before. All official tracking and issue management will continue to happen in Trac to ensure consistency and centralization of information. In the “Mini Tracker” only very simple information like a link to the report, the status of the report and the component associated for filtering purposes will be used. The amount of duplication will be minimal and will only serve for Quality improvement purposes.
• Addressing Potential Confusion: New contributors are not going to receive this protocol without a learning session, explaining how it works. Any new contributor that lands into WP project, GitHub or Trac, can continue doing his things as always. This is not being aimed as a replacement but an improvement. Only people that voluntarily join the Quality group through any of our Onboarding sessions, will be instructed on how to use this and help on developing this new paradigm.
• Reasons to avoiding anything Official in the First Stage: The new process is not being immediately pushed to the main WordPress organization because “almost anything that goes into WordPress organization is a slow process meant to last for a while“. The sole modification of a keyword that was causing filtering conflicts, took @SirLouen almost two months of multiple discussions and follow-ups through multiple dev-chats. Our proposal cannot wait for this long for every single change, as this is still a work in progress. Frequent changes are expected as the proposal becomes more concrete and mature with time: This will be happening simultaneously as the Quality group develops, Just as we did with the First Quality Report, analysing real data to draw meaningful conclusions: we’re excited to provide concrete evidence showing how adjusting certain workflows in Core could be a smart move. This way, we can build on solid facts rather than getting stuck in endless debates without the data to support our ideas.

Actionable Items for Participants

• Select a Component: Attendees are encouraged to choose a specific WordPress component they wish to specialize in.
• Communicate with the group: If unsure about component selection or for any questions, participants can send a message in #test-chat or directly PM any of the test team members.
• Think About Component Maintainership: Consider the possibility of becoming a component maintainer in the future, with support from the presenter to build the necessary skills. This is not required, but we will help through the process.
• Attend Future Sessions: Subsequent sessions will be less theoretical and focus on practical application, component selections, and addressing ongoing questions or problems.
• Review Documentation: Participants are encouraged to read a future post explaining the proposed workflow and the GitHub “Mini-Tracker”

Props to @yashjawale, @krupajnanda, @nikunj8866, and @mosescursor helping review this article and offering feedback.

#contributing-wordpress, #core-components, #meeting, #test-contributors, #wpcontrib