I recently went back to a WordPress Core ticket because a familiar problem kept bothering me: the database could contain the right value while the object cache still told the site something else. Working on that patch reminded me that the hard part of contributing is often not writing code. It is making the problem understandable and the proposed fix safe for everyone else.
Devin Walker has written about returning to Core and finding that many “good first bugs” already had patches. His useful suggestion is to test somebody else's work. I agree. A project needs people who can reproduce an issue, check a patch in a real environment and stay for the review as much as it needs another pull request.
Start with a failure you can explain
My example is WordPress Core ticket #40052. An unchanged metadata update can leave stale cached data behind. In a small test, I primed a user's metadata cache with an old value, changed the database value directly, then called update_user_meta() with that new value. The database had no row to change, so the update returned false; the old cached value could remain. On a site using Redis or another persistent object cache, that sort of disagreement is more than a laboratory curiosity.
I prepared a narrow fix and regression test in wordpress-develop PR #14760. At the time of writing it is an open draft PR, not a merged Core change. Local focused tests and CI give me evidence to ask for review; they do not give me the right to call the bug fixed in WordPress.
That is a useful pattern for any open source project: show the old behaviour, add a test that fails for the right reason, change the smallest relevant path, and run the test again. Record the environment and the exact branch or patch so someone else can repeat it. If another contributor already has a patch, test that one first and report what happened.
What to contribute before you write code
- Confirm the issue. Read the whole ticket, related issues, and existing pull requests. Check whether the behaviour still occurs on the current development branch.
- Write a minimal reproduction. Include inputs, expected result, actual result and the version or environment. Remove customer data and secrets.
- Test the proposed fix. Try the ordinary case, the edge case, and a case that should remain unchanged. Give the maintainer a result they can use, including failures.
- Review with a question in mind. Does the test cover the reported bug? Does the patch change more than necessary? What happens with an object cache, an older PHP version or an empty value?
- Stay involved. Reply to review, revise the patch and report when you can no longer work on it. A pull request is the start of collaboration.
Documentation, translations, accessibility testing, support replies and triage also count. Choose the contribution the project needs, then follow its contribution guide and code of conduct. The same method works outside WordPress: find the project's issue tracker, reproduce the problem and send evidence in the format maintainers ask for.
A good plugin is another way to contribute
A plugin can solve a problem for your own site and still be useful to others, but only if its assumptions travel well. I have been preparing public source and release packages for some of my WordPress plugins. That work has made the difference between “it runs here” and “someone else can install, understand, update and remove it” very plain.
- Give it one clear job. State what it does, what it does not do and which WordPress and PHP versions it supports. Keep site-specific settings out of the public package.
- Use WordPress conventions. Hook into APIs rather than editing Core, prefix or namespace your identifiers, check capabilities and nonces on writes, validate input and escape output. Keep the Plugin Handbook beside the code.
- Make lifecycle behaviour predictable. Activation should be safe to repeat, upgrades should preserve data, and uninstall should say exactly what it removes. Avoid surprising remote calls, background jobs or admin notices.
- Test the actual release. Run syntax and focused behaviour tests, Plugin Check, and an install and upgrade test from the ZIP you plan to ship. Keep the source corresponding to that ZIP. A green automated scan cannot prove an external service works or that the user journey is good.
- Respect the directory and users. Check the WordPress.org plugin guidelines, document privacy and external services clearly, and make support and security reporting easy to find.
For example, preparing Ace Crawl Enhancer for a broader release has meant identifying the files the plugin genuinely needs, keeping site-specific behaviour in adapters, and checking a reproducible package. That preparation is valuable, but it is separate from directory approval and a live install. The distinction matters to the person deciding whether to trust a plugin.
Use AI as a tool that leaves evidence
An assistant can help search tickets, build a local test harness, suggest edge cases and draft a patch. I still need to check what it changed and what it claimed. I disclose meaningful assistance where the project requests it, and I keep generated tests tied to a behaviour I understand. A fast patch with a plausible description is not a substitute for reproducing the fault. If the assistant tests another person's patch, I want the exact command, revision and result in the report.
A first contribution you can make this week
Pick a project you use. Find an issue with a patch and no recent test report. Reproduce the original problem on a disposable local setup, apply the patch, rerun the same steps and comment with your version, commands and observations. If you cannot reproduce it, say so precisely. If you find a missing edge case, write it down before proposing new code.
For WordPress Core, start with the Core Contributor Handbook, the Trac ticket tracker and the development repository. For plugins, start with the Plugin Handbook and build something small enough that you can test and support it. Open source improves when each contribution makes the next person's work easier to verify.