Re: [RFC] Working Groups

On Fri, Jun 12, 2026, at 12:06 PM, Ben Ramsey wrote: >> 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