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
