Proposal: Document WordPress Contributor Toolkit for Core Testing (Bug Reproduction & Patch Testing) in "Get Setup for Testing" #189

Propose adding documentation to the Get Set Up for Testing section of the Test Handbook on how to use the official WordPress Contributor Toolkit desktop app (maintained by @juanmaguitar) for both Bug Reproduction and Patch/PR Testing.

We can also mention the WP Trac Triager Chrome extension as an optional companion tool for contributors who want a 1-click shortcut from Trac into the desktop app.

Background & The Problem

In the Make WordPress Test Team, testing primarily involves two workflows:

1. Bug / Issue Reproduction: Testing reported issues against clean WordPress trunk to confirm whether a bug exists and verify reproduction steps.
2. Patch & PR Testing: Applying proposed patches/PRs to confirm the fix works and doesn't introduce regressions.

Currently, the handbook under get-setup-for-testing/ only covers:

• WordPress Playground: Browser-based, but cannot test .patch or .diff attachments from Trac, and lack of persistence makes deeper bug reproduction difficult.
• Local Environment with Docker: Powerful, but has a steep barrier to entry (Git, Node.js, npm, Docker Desktop). As noted in contributor-day.md, configuring Docker frequently consumes an entire Contributor Day session.

There is currently no documented option for contributors who need a persistent, zero-prerequisite local environment for both reproducing bugs and testing Trac .diff patches without installing and configuring Docker.

The Proposed Solution: WordPress Contributor Toolkit

Document the WordPress Contributor Toolkit as an officially recommended environment option under get-setup-for-testing.

Key Features of the Contributor Toolkit:

• Zero Prerequisites: Self-contained desktop app (macOS Apple Silicon, Windows, Linux) bundling Git, Node.js, npm, and a local server—no Docker or CLI configuration required on the host machine.
• Bug Reproduction: Easily spins up a fresh, persistent trunk instance with built-in logs, database inspection, and mail catching to observe and confirm reported bugs.
• Patch & PR Testing: Supports both GitHub PRs and traditional Trac .diff/.patch files with visual conflict inspection, 1-click apply, auto-rebuild, and clean 1-click revert.
• Standalone by Default: Contributors can simply enter any ticket number or URL directly into the app to start working.
• Optional Trac Integration: The app registers the wpct:// protocol, meaning contributors who optionally use browser tools like WP Trac Triager can click 🧰 Open in Contributor Toolkit right from Trac for instant handoff.

Relevant Tools & Attribution

• Main Tool — WordPress Contributor Toolkit: Desktop app led and maintained by @juanmaguitar alongside community contributors (WordPress/contributor-toolkit).
• Optional Helper — WP Trac Triager: An optional Chrome extension also created by @juanmaguitar that adds a 1-click deep-link button directly inside the Core Trac sidebar.

Proposed Workflows to Document

1. Installation & Setup: Downloading and running the Contributor Toolkit app with zero dependencies.
2. Connecting a Ticket:
   • Primary Method: Entering the ticket number or URL inside the app.
   • Optional Shortcut: Using WP Trac Triager's 🧰 Open in Contributor Toolkit button on Trac.
3. Workflow A – Bug Reproduction: Running a clean trunk instance, checking debug logs/database/mail, and submitting an Issue Reproduction Report.
4. Workflow B – Patch & PR Testing: Applying Trac .diff/.patch attachments or GitHub PRs, verifying fixes, reverting cleanly back to trunk, and submitting a Patch Test Report.
5. Contributor Day Reference: Mentioning it in contributor-day.md as an accessible setup alternative for attendees to avoid Docker delays over venue Wi-Fi.

💬 Feedback Needed / Questions for the Team

We would love the Test Team's thoughts on how this should be structured in the handbook:

• Option 1 (Dedicated New Page): Create a standalone guide under get-setup-for-testing/ (similar to how we have test-core-tickets-with-playground.md and test-core-tickets-with-grunt.md), covering both bug reproduction and patch testing with the Toolkit from start to finish.
• Option 2 (Integrate into Existing Pages): Update existing pages (such as set-up-a-testing-environment.md and index.md) to include Contributor Toolkit as an environment option, without creating an entirely new page.

Which approach would provide the best onboarding experience for new testers?

Next Steps

• Gather feedback from team members here and during an upcoming #core-test Slack meeting.
• Based on the consensus (Option 1 vs Option 2), prepare and submit a Pull Request.