I’m thrilled to share how the Shipping WordPress Without Shipping Code talk went at WordCamp Canada 2025 (aka “WCEH”; get it WC, eh?). For folks who couldn’t attend, here’s a summary of what we covered, insights from the audience, and next steps you can try yourself.
If you’d rather watch than read, here’s the full WordCamp Canada 2025 talk:
In the talk I walked my own path, from helper to release deputy to AI team lead, all without ever having commit access. Along the way I shared how non-developer roles often get overlooked, practical patterns I’ve used to keep releases moving, and encouragement for designers, strategists, writers, or project leads who want to jump into this space. Here’s how the session unfolded, with some highlights and sample quotes.
Opening & Framing
I started by confronting the myth that only engineers lead in open source. My aim was to shift perspectives: YOU can lead, even if your strengths lie outside code.
The Historical Gap
We talked about how WordPress projects have historically lacked project and product management support, and how that gap creates friction. I quoted from the WordPress release handbook:
“The main focus of the release team is to lead the release from its beginning through to launch … to act as connectors and facilitators.”
It resonated: many in the audience nodded when I called out that non-developer contributions are often invisible or undervalued.
My Journey
I shared my own timeline: involvement in WordPress 4.7, then 4.8, 4.9, 5.8, 6.1, and 6.8. I also noted that WordPress 4.7 had 482 contributors, including 205 first-timers, to emphasize how major release cycles need more scaffolding than code alone in order to support that many new contributors.
What “Glue Work” Looks Like
This was a core section of my talk. We broke down how “glue work” such as triage, alignment, decision logging, and volunteer motivation is the connective tissue in a release. I used the quote:
“Triage is the practice of reviewing existing issues to be sure they are relevant and actionable.”
And I referenced how Apache PMC members and Kubernetes maintain non-coding roles, showing that this isn’t just WordPress-specific but a pattern in mature open source communities.
Tools, Patterns, & Gotchas
Here, the audience got actionable advice. Some highlights:
- Use GitHub issues and projects with clear labels (
needs-decision,punt, etc.) - Maintain decision logs so the same debates don’t repeat
- Establish scope gates (feature freeze, RC readiness) to protect the release timeline (go/no go decisions)
- Beware burnout and invisible labor
I referenced Karl Fogel’s Producing Open Source Software from my notes in a recent WordPress Book Club hosted by Aaron Jorbin roughly as ~“If it’s not written down, it didn’t happen.” And Nadia Eghbal’s note that “Maintainers simply don’t have the energy to onboard every person who shows passing interest.”
From Contributor to Leader
We laid out a three-step path:
- Start small: take notes, triage, run a meeting agenda.
- Own a lane: coordinate docs, dev notes, or release notes.
- Lead a release: coordinate across teams, make decisions, facilitate.
I also referenced the Kubernetes “leads and shadows” model as something WordPress could use to mentor future contributors.
Practical Playbook
Seven habits you can take into your own contributor journey:
- Write the agenda, end on time
- Keep a decision log
- Guard scope with labels
- Close stale issues
- Default to public and async
- Give credit often
- Leave breadcrumbs
I urged the audience to pick one habit and try it immediately.
Takeaways and Q&A
I wrapped up by reinforcing that leadership lives outside the repo and glue work makes shipping possible. I invited folks to pick a lane, join a triage session, or help curate the next release.
The question period surfaced great stories: people surprised they could participate in release work without code, and others asking how to balance contributions with full-time jobs.
What I Learned from the Room
- Many talented people hesitate because they don’t see non-developers in core.
- The “playbook” habits resonated; people wrote them down quickly.
- There’s appetite for more structured mentorship paths for project contributors.
- Some folks suggested pairing systems (non-developer lead and developer lead) to onboard new contributors.
Next Moves You Can Try
- Join the next WordPress core triage or bug scrub session.
- Volunteer to take notes for a devchat.
- Pick one of the seven playbook habits and try it in your own project or team.
- Consider how your current job or project might adopt glue roles, like coordinating features, managing scope, or writing decisions.
Final Thoughts & Thanks
Before wrapping up, I have to say how special it was to experience WordCamp Canada in Ottawa. The Carleton University campus was absolutely stunning, with crisp fall air, the leaves just starting to turn, and Richcraft Hall overlooking the canal and nearby lake creating an incredible setting.
Ottawa itself is a beautiful mix of history and energy, with old architecture and monuments along the Ottawa River that show how much care the city puts into preserving its character.
And of course, none of this would have been possible without the amazing organizers, volunteers, and sponsors who made WordCamp Canada feel every bit like the flagship event it is becoming. The warmth and generosity of the Canadian WordPress community really stood out, from hallway conversations to contributor day collaborations.
Running this talk in Canada felt meaningful. It’s part of a larger conversation: WordPress needs more voices who see beyond code, people who connect, facilitate, and help the system work. I can’t wait to see what happens when more contributors realize they are leaders already.
If you were in the session, thank you. If we met, thanks again. If not, I hope you’ll drop me a line, try one small piece of this playbook, and remember that leadership doesn’t always look like a commit; sometimes it’s the work no one sees, but everyone depends on.
If you missed the talk, then below are my slides.
