I'm opening discussion on an RFC to create a policy for PHP project
working groups:
https://wiki.php.net/rfc/working_groups
The RFC "establishes a framework for the creation, operation, and
dissolution of working groups within the PHP Project. It provides a
structured, transparent mechanism for managing discrete projects or
activities (whether technical, infrastructural, or otherwise) undertaken
by the Community. As such, it ensures that each working group is clearly
chartered, time-bound, and actively led, thereby addressing
organizational gaps that often leave new and existing volunteers
uncertain about who to talk to or how to contribute."
I created the first draft of this RFC a few years ago but decided
against formally proposing and discussing it on the list. Roman's recent
social media policy RFC1 made me change my mind. I think the time for
defining formal working groups in the PHP project is here.
Under a working groups policy, someone could propose a marketing
communications working group to manage and make decisions about how the
PHP project communicates with its community.
Another example is that someone (i.e., Derick) could propose an
infrastructure working group for managing all the systems, credentials,
etc. for the PHP project. This group already exists informally, but a
working group would formalize it. (A potential charter for such a
working group is provided as an example in the RFC.)
Cheers,
Ben
I'm opening discussion on an RFC to create a policy for PHP project
working groups:https://wiki.php.net/rfc/working_groups
The RFC "establishes a framework for the creation, operation, and
dissolution of working groups within the PHP Project. It provides a
structured, transparent mechanism for managing discrete projects or
activities (whether technical, infrastructural, or otherwise) undertaken
by the Community. As such, it ensures that each working group is clearly
chartered, time-bound, and actively led, thereby addressing
organizational gaps that often leave new and existing volunteers
uncertain about who to talk to or how to contribute."I created the first draft of this RFC a few years ago but decided
against formally proposing and discussing it on the list. Roman's recent
social media policy RFC1 made me change my mind. I think the time for
defining formal working groups in the PHP project is here.Under a working groups policy, someone could propose a marketing
communications working group to manage and make decisions about how the
PHP project communicates with its community.Another example is that someone (i.e., Derick) could propose an
infrastructure working group for managing all the systems, credentials,
etc. for the PHP project. This group already exists informally, but a
working group would formalize it. (A potential charter for such a
working group is provided as an example in the RFC.)Cheers,
Ben
I'm not sure why this has gotten so little (any?) feedback. It's actually incredibly important to help unblock a lot of support tasks for the PHP project and ecosystem. I fully support this proposal.
--Larry Garfield
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:
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
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.
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 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.
Best regards
Tim Düsterhus
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: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 Proposals1 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 Types3 might benefit from a working group. The True Async4
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
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.
I could see a "modules" working group as well, given that there's so many divergent views on it. Async and Generics could also stand working groups. But yes, most RFCs wouldn't need a formal WG.
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 would also note here that having a clear process in place for "working groups" (how they're created, expired, kept in check, populated, etc.) makes it easier to propose specific working groups (eg, for social media). A lot of the boilerplate is then already defined, and defined consistently for all WGs. That way, we don't have an issue with one particular WG's charter forgetting to include a "how to fire bad actors" statement or something, because that's already pre-defined. (Humans WILL forget things, and no, review won't always catch it.)
I would much rather formalize WGs, then use that framework to define a social media WG, than to one-off social media and then have something else defined in some other subtly different way later.
--Larry Garfield
Hi
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:
Best regards
Tim Düsterhus
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:
- Name
- Purpose
- Duration
- Activities
- Membership
- 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
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-groupsI'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.
My 2cents in the form of questions (because I might have missed something):
Since the PHPF's role is to support, help and discuss, then shouldn't
PHPF operatives be excluded from voting on RFCs, whatever the involved
WG? It would ensure that the PHP voters (aka "/The community that
includes contributors and core team members/") can take decisions
without the PHPF being able to intervene if there's a disagreement
between the two groups, I guess...?
And similarly, shouldn't there be a mandatory consultation from the PHP
community when the PHPF actually operates on something that impacts the
community on non-RFC-mandatory-operations, like marketing,
communication, etc.? I mean, if at some point the PHPF communicates on
the web on something the PHP community would disagree with (concluded
via a vote of whatever sort), shouldn't the PHPF, as a "consultative
agency", have to update their acts and productions to fit to the
community's views? (that would solve parts of the issues with the recent
hot discussions on a certain link to a certain platform on PHP's
website, for example).
All these questions are here because PHP has no official governance
other than the (sometimes vaguely) designated "PHP Community", and the
PHPF's role, from what I understand, is mostly to help the community to
decide and act on PHP-related tasks, but not directly decide nor act.
I might be off of some details, so feel free to correct me if I miss
something, if I'm mistaking, or if I misunderstand certain roles or notions.