Re: [RFC] Working Groups

Hi On 6/12/26 19:06, Ben Ramsey wrote:

I was following the Feature Proposals[1] policy, which doesn't include this information. It might be worth updating the Feature Proposals policy to include text about creating an initial pull request for policy RFCs, as well as clarifying that this is intended for creation of new policies as well as amending existing policies (the Policy Repository RFC only states that a PR must be created first when you're amending a policy).

Indeed, it seems that “how to do a policy RFC” is not actually written down anywhere in the policies repository. It makes sense to me to have a small amendment there to have a “policy proposals” policy that refers to the “feature proposals” policy and just indicates the policy-specific specialities.

As for the RFC itself, as I think I had already mentioned on social media back then, it is unclear what value this additional policy brings. Given that everything relating to a working group needs to go through an RFC anyways (which is a good and important rule), I don't quite see why we would need another policy on top of the (policy) RFC process itself.

I believe I've explained at length what I think the value is in the RFC's non-normative discussion section, particularly under Rationale.[2] Is there something specific I can elaborate on that's unclear, or are you saying you disagree with the rationale?

I'm not disagreeing with the value of having *working groups*, which from what I understand is what the rationale mainly focuses on. I'm just not seeing a value in having this extra policy, since it doesn't enable anything new as evidenced by Roman's social media policy RFC, which in practice is just proposing a “social media working group” with guardrails as to what this working group may or may not do. In fact, I feel that it takes some flexibility in how working groups may be structured according to their unique requirements.

This leaves the non-language tasks, such as marketing. I expect there to be a need for less than a handful of this kind of “working group” or “team”, which I believe can easily be handled with the existing RFC process. In fact Roman's social media RFC that you referenced in your email is already proposing to create a “working group” (or officially delegating responsibilities) even without the featured RFC being accepted.

My RFC defines a set of expectations we would require for any such working group and provides a mechanism for anyone in the community to propose a working group. You're right that the lack of a mechanism doesn't restrict anyone from doing this (as evidenced by Roman's RFC), but it definitely doesn't encourage involvement, and I've tried my best through the discussion on the RFC to argue in favor of encouraging broader community involvement by signaling that (a) we're welcoming of others creating initiatives within the PHP project, and (b) we trust and empower these initiatives to operate and make decisions without a formal project hierarchy or BDFL.

I believe this special empowerment of a group smaller than “the entire voter base” to make decisions for the PHP project is something that is rarely needed. I can only think of social media and infrastructure here. Maybe the security team, but that already is a thing and the empowerment there comes from collaborating closely with the core developers and release managers. Anything that doesn't need special powers can more efficiently be organized without the overhead of the initial RFC, as can also be seen by The PHP Foundation planning to launch 6 “special interest groups” in the remainder of 2026 without needing to involve the PHP project: https://thephp.foundation/blog/2026/06/11/integrating-community-feedback-into-foundation-strategy-part2/#community-special-interest-groups Best regards Tim Düsterhus