Re: [RFC] Working Groups

On 6/8/26 08:56, Tim Düsterhus wrote:

Hi Am 2026-05-26 18:15, schrieb Ben Ramsey:

I'm opening discussion on an RFC to create a policy for PHP project working groups: https://wiki.php.net/rfc/working_groups

Thank you for the RFC. Purely policy-wise, any policy RFC should consist of a PR to https://github.com/php/policies/ as the “source of truth” with the RFC text itself only being a stub that references the PR and that provides supplementary information. See: https:// wiki.php.net/rfc/ policy-repository

Tim, thank you for reviewing the RFC. 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). The Working Groups RFC is clear about what parts of the RFC go into the policy document:

Upon acceptance, this PHP RFC adds a new document, working- groups.rst, to the PHP policies repository. The document working- groups.rst MUST contain the contents of the Introduction and Working Groups sections of this RFC.

I've also opened a PR for this: https://github.com/php/policies/pull/35

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 disagree that this is "on top of the (policy) RFC process." This is orthogonal to the RFC process. However, it is complementary. Yes, the RFC process is used to charter a working group. This provides transparency and allows the community to decide what working groups are important to the PHP Project. But a working group does not need an RFC for every decision it makes or activity it undertakes. Approval of a working group charter is the community saying, "we grant you permission to operate according to your charter." This is empowerment. The goal of working groups is empowerment. I can propose a Bike Shed Working Group that's chartered with the specific purpose of operating and maintaining the bike shed. The community agrees it's important and grants the group authority to operate and maintain the bike shed without needing to ask for broad approval for every single decision it makes (this is done through voting in favor to approve the working group's charter). Now, when the bike shed needs to be painted, the working group, whose charter says it operates and maintains the bike shed, can decide what color to paint it without needing full community approval. Meanwhile, working groups must be transparent in their decisions. The Bike Shed WG must have methods for the community to provide feedback, but the community has entrusted the working group with the authority to make decisions, and the working group has the final say in the bike shed's color. Nevertheless, working groups are accountable to the community. The Working Groups policy describes the process the community may take if it feels a working group has gone beyond their charter or is acting in bad faith. I hope that doesn't happen, but the policy provides community-led remediation in the event it does. That said, working groups cannot operate outside the RFC process for PHP language or policy changes: "If a working group's activities include making changes to the PHP programming language and/or PHP Project policies, the working group MUST follow the PHP RFC process to propose these changes."

For language RFCs, RFC authors are already working with the list and their co-authors to figure out the best possible version for a given proposal without any official “working group”. In practice, these kinds of RFCs work best when done with a very small team of “subject matter experts” that have done their research before proposing the RFC and where the discussion only makes minor adjustments.

This is true, and as the RFC states, "creating a working group is not a requirement for creating a PHP RFC." Language RFC authors and co-authors may continue to operate as they have, without needing to charter a working group. However, "working groups MAY propose PHP RFCs as part of their activities," and if they want to make changes to the language, they "MUST follow the PHP RFC process to propose these changes." I don't see value in creating a working group for the sake of working on a specific RFC. RFCs for features like the pipe operator, property hooks, the URI extension, DOM changes, etc. probably would not benefit from having working groups. One could argue that Larry's initiative for Algebraic Data Types[3] might benefit from a working group. The True Async[4] project might also benefit. But I don't think either of these require the thing that a working group provides: operational autonomy (i.e., empowerment). If a group who wants to design language features (and thus create RFCs) also needs operational autonomy for something, then it would be valuable for them to propose a working group.

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. Cheers, Ben [1]: https://github.com/php/policies/blob/main/feature-proposals.rst [2]: https://wiki.php.net/rfc/working_groups#rationale [3]: https://wiki.php.net/rfc/adts [4]: https://true-async.github.io/