WooCommerce GitHub issues are getting pruned in bulk: unassigned bug reports opened between 2018 and 2020 with no recent activity, reports where maintainers asked for more detail and never got it, and issues filed in the wrong repository or support channel. James Kemp announced the sweep on the WooCommerce developer blog. I think it’s overdue. A lot of those issues were never actionable because they were reported in the wrong place, and that mistake is still the default one.
Where WooCommerce GitHub issues belong
An issue on woocommerce/woocommerce is the right place when you can reproduce a bug on a clean install and describe it in steps another person can follow: WordPress version, WooCommerce version, what you did, what you expected, what happened instead. That repo is where maintainers triage, label, and schedule core fixes, so it rewards reports that read like test cases. If your report needs a paragraph about the client’s setup before the bug even appears, it probably isn’t a core issue yet.
The WordPress.org support forum for the WooCommerce plugin is where store owners should start. Volunteers and plugin representatives answer there, and the first suggestions are to disable plugins and switch to a default theme, because on a live store with thirty plugins that’s usually where the problem lives. It’s slower and less satisfying than filing an issue, but a conflict with a checkout plugin is a site problem, and filing it as a core bug just adds to the pile being closed now.
woocommerce.com support tickets are for anything you licensed there: marketplace extensions, hosted products, premium features. A bug in a paid extension belongs in a ticket with your license details, not in the core repo. GitHub Discussions is the fourth place, for questions and ideas that aren’t defects.
So, per site: if you develop and can reproduce the bug on a stock install, file a GitHub issue. If a client store is misbehaving and you haven’t isolated the cause, start a forum thread and isolate first. And if the problem is in a paid extension, open a ticket. I’ve written before about what it takes to host a repo under the WordPress GitHub org, and triage discipline is most of that job.
Reopen the old issue or file a new one
If an issue you follow gets closed in this sweep, you have two options, and the announcement is clear about which to use: open a new issue rather than reopening the old thread. I agree, and not just to be tidy. Checkout moved to the block implementation, high-performance order storage arrived, PHP versions changed. Reproduction steps written against WooCommerce 4.x in 2019 rarely still apply, and a reopened thread drags forty comments of stale context into triage with it. (I don’t know what share of those old reports still reproduces, and neither do the maintainers, which is the argument for closing them rather than auditing each one.)
The exception is an old issue that still describes current behavior, sometimes with a linked pull request or a maintainer explaining why it stalled. Even then, don’t resurrect it. Open a new issue, link the old one, and say which parts still reproduce. You keep the history searchable without making anyone re-read it.
The announcement lists what a fresh report needs: WordPress and WooCommerce versions, steps to reproduce, expected and actual behavior, environment details, and links to related issues. Most of that is two minutes of WP-CLI away:
wp core version
wp plugin list --fields=name,version --status=active
wp eval 'echo WC()->version;'Then attach the system report from WooCommerce > Status > Get system report. It tells a maintainer what your environment looks like without either of you guessing.
What the new rules mean for AI-drafted pull requests
Alongside the cleanup, the Community contributions page was updated, and it spells out what reviewers need: link the PR to an issue, run tests and linting locally before submitting, fill out the full template including test steps, and respond to automated AI review feedback or explain why it doesn’t apply. Pull requests that need changes can get a needs: author feedback label, and ones that sit unanswered may be closed so the review queue stays honest.
Compare two submissions. One is a large AI-generated PR touching a dozen files, aimed at a bug nobody confirmed. The other is a fifteen-line patch you wrote after reproducing the issue and running the test suite. The second one gets merged. Review attention is the scarce resource, and the announcement says plainly that AI tools are welcome but the contributor is still responsible for understanding the submitted code and verifying it works. That’s the right line to draw.
In practice: reproduce the bug yourself before letting a tool draft the fix, run the tests locally, and be ready to explain any line in the diff. If you can’t, the PR isn’t ready, whichever of you typed it.
This week on client sites, I’d run those three WP-CLI commands and record the versions. I’d check which of my subscribed issues were closed in the sweep, and refile any that still bite as fresh reports with the system report attached. If you want a hand reproducing a WooCommerce bug or deciding which channel it belongs in, that’s work I do regularly.
