In February 2025 I was announced as one of the WordPress.org Hosting Team Representatives for 2025. It's a role I'd been working toward — not by campaigning for it, but by showing up consistently over a couple of years and trying to make myself useful.
Team Reps in the WordPress contributor ecosystem aren't elected officials. They're more like anchors — people who take responsibility for keeping a team coordinated, communicating outward to the broader project, and making sure the team's concerns get heard in the right conversations. The Hosting team has two reps, and I serve alongside another contributor who brings different experience to the role.
What the Hosting Team Actually Does
The WordPress Hosting team is one of the less visible teams in the project, which is ironic given how much of WordPress's success depends on the quality of the hosting environments it runs on. The team's work falls into a few categories: producing the Recommended WordPress Hosting requirements, coordinating compatibility testing before major releases, maintaining documentation for hosting providers, and surfacing hosting-specific issues to Core developers before they ship in a release.
That last one is the part I care most about. There's a persistent gap between how Core developers think about the environments their code will run in and the reality of what hosting providers actually configure. PHP version support windows, server-side cron reliability, object cache assumptions — these differences cause real pain for hosting engineers and the site owners they support. The Hosting team exists partly to close that gap.
How I Got There
I started contributing to the Hosting team before I had any formal role in it. My day job at Rocket.net gave me direct experience with the hosting infrastructure questions the team was working on — Redis configuration, PHP memory constraints, server-level caching behavior. I had opinions, and the team was a place where those opinions could become useful input.
Over time I took on more responsibilities: leading the Hosting table at Contributor Days (WordCamp Asia 2025, WordCamp US 2025, WordCamp Europe 2025), helping coordinate team meetings, contributing to documentation projects. The rep nomination came after that track record was established. It wasn't a sudden promotion — it was the team formalizing what had already been happening organically.
If you work in WordPress hosting and want to contribute meaningfully to the project, the Hosting team is consistently one of the most welcoming entry points. The team meets weekly in Slack and always has work that needs doing.
What the Rep Role Involves
In practice, being a team rep means a few things. I represent the Hosting team in cross-team discussions — Core team meetings, release squad conversations, planning calls for major features that touch server-side behavior. When a Core change has hosting implications that the dev team hasn't thought through, it's my job to flag it before it ships.
I also manage the internal rhythm of the team: weekly meeting agendas, making sure action items from previous weeks are tracked, keeping the team's public make.wordpress.org posts current so the broader community can follow what we're working on. A lot of it is coordination work that doesn't produce visible output, but without it the more interesting work stalls.
What I Want the Team to Be
The hosting layer is where most WordPress failures actually happen. Not because WordPress is poorly written, but because the distance between a development environment and a production server is real, and the assumptions baked into WordPress Core are sometimes wrong about what production looks like.
I want the Hosting team to be the bridge that closes that distance — not just by writing documentation, but by being in the room when decisions get made. That requires sustained presence across multiple WordPress release cycles, which is exactly what I'm trying to build.
