# Who Do I Talk To? **The Case for PHP Working Groups** By Ben Ramsey Published on July 12, 2026 I speak at conferences and organize user groups, and I spend a lot of that time encouraging people to contribute to PHP and other open source projects. Inevitably, someone approaches me at an event and asks, "Who do I talk to about contributing to this or that?" Sometimes, I know the answer: "Go talk to so-and-so." More often, I say, "Let me find out, and I'll get back to you." I mean it when I say it. Then, life happens, and I don't get back to them, or by the time I do, they've lost interest or moved on, their initial enthusiasm having fizzled out. I've also heard from folks who tell me they've tried to get involved—they sent an email or asked around—and never heard back. This isn't a tale about rudeness or gatekeeping. Everyone means well, but it keeps repeating, and every time it does, we lose someone. Enthusiasm for contributing has a short shelf life. > Their enthusiasm fizzles out before it has a chance to catch fire. {: .pullquote } To solve this problem, I've proposed [an RFC to establish working groups](https://wiki.php.net/rfc/working_groups) in the PHP project. Before I explain what they are, I want to explain why I believe we need them. The PHP project has no shortage of work to do and no shortage of folks willing to do it. What it lacks is a visible place to plug in. The RFC process serves us well for changing the language, but the operational side of the project (i.e., infrastructure, websites, contributor onboarding, outreach) runs on informal arrangements, with no clear ownership, no defined membership, and no standard way for a new volunteer to raise their hand and get involved. When someone asks, "Who do I talk to?" the honest answer is often that nobody knows because the answer lives in people's heads rather than in any structure we can point to. When the conversation turns to problems with PHP's governance, someone will often suggest the project needs a [BDFL](https://en.wikipedia.org/wiki/Benevolent_dictator_for_life): one person with a vision and the final say, a benevolent dictator to break ties and drive the language forward. I understand the appeal, but PHP has never had one, and this was by design. [In a 2002 *SitePoint* interview](https://web.archive.org/web/20091206104355/articles.sitepoint.com/article/phps-creator-rasmus-lerdorf), Rasmus Lerdorf, creator of PHP, said: > First, to be clear, I did not develop the PHP we know today. Dozens, if not hundreds of people, developed PHP. I was simply the first developer. In the same interview, he described himself as "simply the first member of a community that has arisen around one approach to solving the web problem." [On a 2003 IT Conversations podcast](https://web.archive.org/web/20071221001310/itc.conversationsnetwork.org/shows/detail58.html), he went further: > There was never any intent to write a programming language. People like Larry Wall and Guido van Rossum, they know how to write programming languages. I have absolutely no idea how to write a programming language. I just kept adding the next logical step along the way, and eventually it became a programming language—with a lot of help from other people, as well. PHP took over the web without a master plan and without a dictator, benevolent or otherwise. Even in the eras we remember as well-led, the people leading it did so by doing the research, building the case, and winning the votes. There were no decrees from on high. Leadership in this project has always been earned through work and persuasion, never granted by title. Whatever is missing from PHP's governance, it isn't a throne, and any structure we add should fit the shape of the project we actually have. That's what the Working Groups RFC tries to do. Any community member may propose a working group by writing a charter—its purpose, duration, activities, membership process, and communication plan—and submitting it through the RFC process we already have. When the community accepts the charter, it grants the group authority to operate within its scope without needing a new RFC for every decision the group makes. To understand what that grant of authority means, let's imagine a Bike Shed Working Group, chartered for the specific purpose of operating and maintaining the bike shed. If the community agrees the bike shed matters, it approves the charter and entrusts the group with the shed's upkeep. Now, when the shed needs painting, the working group decides what color to paint it. There is no need for community-wide approval for a decision squarely within the group's scope. The group must still be transparent—the community can see its decisions and offer feedback—but the group has the final say on the color of the shed. This is empowerment. Approving a charter is the community saying, "we trust you to do this work." That's the spirit in which I've proposed this, and it's the spirit I hope working groups will carry forward. Note what working groups are *not*. They create no hierarchy. No group outranks another, no group has authority over anything outside its scope, and no charter can bypass the RFC process. Changes to the language or to global project policies still require RFCs, even when a working group proposes them. Some have reasonably asked what this policy adds when a charter must go through the RFC process anyway. It's a fair question, and my answer is that the working group policy is orthogonal to the RFC process but complementary. The RFC process is how a group is chartered; the policy defines what every charter must include—purpose, duration, membership, how the group communicates, how it winds down—so that each working group proposal starts from the same foundation. The RFC process approves working groups; the policy is what sets common, agreed-upon standards that all working groups must follow. I'll be honest about the thing that worries me most about my own proposal. I worry it could be read—or, worse, used—as bureaucracy, a barrier where I intended a door. Slowing things down is the opposite of my intent. The charters and the annual reports aren't process for the sake of process. They're the price of transparency, and I've tried to keep the price low. If you read the policy and find a wrinkle that could be mistaken for a barrier to participation, I want to know about it so we can iron it out before this comes to a vote. Please chime in on [the mailing list](https://news-web.php.net/php.internals/131021). > [!HINT] > From the [mailing list message page](https://news-web.php.net/php.internals/131021), click the "Send a blank email to…" link to get a copy of the message. It'll send you the actual mailing list message, which you may reply to from your mail program to participate in the discussion. There's one more piece, and it circles back to where I started. Remember that I'm the person who says "I'll get back to you" and then forgets. This policy is designed so that no volunteer's enthusiasm ever depends on my follow-through or anyone else's. Every charter declares how to become a member and sets the group's duration. A group that has finished its work or has quietly gone dormant may be dissolved through the same RFC process that created it, and anyone may then charter a new group to pick up where the old one left off. There's already energy for this sort of thing. An RFC under discussion right now proposes [a social media team](https://wiki.php.net/rfc/social-media-policy) for PHP. Imagine that effort with a charter behind it. The infrastructure that keeps php.net running is exactly the kind of work a charter could make visible and welcoming to newcomers. And nothing says working groups are only for code and servers: documentation, mentorship, onboarding, outreach, and more are ripe for becoming PHP project working groups. Contributing to PHP has never been only about C patches. So, here's my question for you: what would you charter? Read [the RFC](https://wiki.php.net/rfc/working_groups) and join [the discussion](https://news-web.php.net/php.internals/131021). The next time someone walks up to me at a conference and asks, "Who do I talk to about helping out?" I'd love for the answer to be a link to a charter so that spark of enthusiasm finally has somewhere to catch.