On 6/12/26 12:52, Tim Düsterhus wrote:
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.
I think a defined policy and procedure is a strong signal both
internally and externally of a healthy community. The Working Groups
policy is extremely flexible, while providing a common structure for
charters and a place to find the charters.
That structure is:
1. Name
2. Purpose
3. Duration
4. Activities
5. Membership
6. Communication Plan
These are the common sections all working groups will need to provide,
but they may also add any other sections that are necessary "according
to their unique requirements."
These sections are fairly common to see in any group charters across
other organizations and industries. I didn't make them up.
Following this template provides consistency and makes the charter
easy-to-read and recognizable. The rest of a working group's policies
and operational procedures would not be maintained within the PHP
policies repository but would be kept within the working group's own
repository. It it helps, I can clarify this and update the policy to
state the PHP Project will provide a public GitHub repository and
mailing list for each chartered working group.
I think Roman's Social Media Policy is too detailed in defining the
policy within the PHP policies repository. The only thing that should be
in the policies repo is the group's charter, not how it operates. Much
of what's defined in the policy should be left to the working group
itself to decide and keep track of within its own repository, so the
working group can be more flexible, while still being transparent and
open to feedback with changes to their operating procedures, etc.
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.
I don't think it's rarely needed, but it's rarely, if ever, happened
because we've never had a process to create groups like this. I think
we've found a fairly good groove for making changes to the language via
mailing list collaboration and the RFC process. These are technical
issues, and internals excels at the technical side, but we have not set
ourselves up for success in operationalizing many of the other aspects
necessary for managing and governing a large open source project of the
scale of PHP. And it shows.
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
I'm aware of the PHP Foundation special interest groups, and Elizabeth
and I discussed them before I opened the Working Groups RFC for
discussion. We agreed they do not cover the same ground as the Working
Groups RFC. By design, the PHP Foundation SIGs have no operational or
governance authority over the PHP Project. There can be
cross-pollination and collaboration between the initiatives, but the
SIGs are external, community-focused, interest groups, while PHP WGs are
internal, PHP Project-focused, operational groups.
Cheers,
Ben
