# [RFC] Working Groups - Thread: https://externals.io/message/131021 - Original archive: https://news-web.php.net/php.internals/131021 - Started by Ben Ramsey on 2026-05-26T16:15:02+00:00 - Messages: 16 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #131021 — Ben Ramsey — 2026-05-26T16:15:02+00:00 URL: https://externals.io/message/131021#131021 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 RFC[1] 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 [1]: https://wiki.php.net/rfc/social-media-policy --- ## #131126 — Larry Garfield — 2026-06-03T20:30:01+00:00 URL: https://externals.io/message/131021#131126 · In reply to: #131021 > 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 RFC[1] 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 > > > [1]: https://wiki.php.net/rfc/social-media-policy 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 --- ## #131169 — tim@bastelstu.be — 2026-06-08T13:56:12+00:00 URL: https://externals.io/message/131021#131169 · In reply to: #131021 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 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 --- ## #131216 — Ben Ramsey — 2026-06-12T17:06:11+00:00 URL: https://externals.io/message/131021#131216 · In reply to: #131169 > Hi > > Am 2026-05-26 18:15, schrieb Ben Ramsey: > > […] > > 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/ --- ## #131220 — Larry Garfield — 2026-06-12T17:29:14+00:00 URL: https://externals.io/message/131021#131220 · In reply to: #131216 > > […] > > > 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. > > […] > > > 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 --- ## #131221 — tim@bastelstu.be — 2026-06-12T17:52:52+00:00 URL: https://externals.io/message/131021#131221 · In reply to: #131216 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. > > […] > > > 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. > > […] > > > 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 --- ## #131223 — Ben Ramsey — 2026-06-12T18:53:51+00:00 URL: https://externals.io/message/131021#131223 · In reply to: #131221 > 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 --- ## #131271 — Alex Rock — 2026-06-15T12:39:42+00:00 URL: https://externals.io/message/131021#131271 · In reply to: #131223 > > […] > > > 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. 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. --- ## #131281 — Larry Garfield — 2026-06-15T15:20:15+00:00 URL: https://externals.io/message/131021#131281 · In reply to: #131271 > > […] > > > 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...? "PHPF operatives" sounds very negative. Bear in mind, the Foundation currently employs a majority of the people who really understand the PHP engine and how to maintain it. Excluding them from voting would be.. project suicide. The Foundation has no vote. The people who do half the work for PHP, who happen to work for the Foundation, have votes. As they should. > 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. From the Foundation's home page: ``` The PHP Foundation is a collective of people and organizations relying on the PHP language. Its mission is to ensure the long-term prosperity of the PHP language. The PHP Foundation focuses on providing financial support and guidance to PHP language developers to support its goals of improving the language for its users, providing high-quality maintenance, and improving the PHP language project to retain current contributors and to integrate new contributors. The PHP Foundation aims to promote the public image of the PHP language in the interest of retaining existing and gaining new users and contributors. Read our announcement for more details. ``` That's what the Foundation does and is for. It really seems like you're inventing problems that do not exist, and have no bearing on the project itself creating working groups. That those WGs may overlap with the Foundation, both in goal and personnel, is a good thing in my mind. --Larry Garfield --- ## #131310 — youkidearitai — 2026-06-16T02:02:57+00:00 URL: https://externals.io/message/131021#131310 · In reply to: #131281 2026年6月16日(火) 1:02 Larry Garfield : > > > > […] > > "PHPF operatives" sounds very negative. Bear in mind, the Foundation currently employs a majority of the people who really understand the PHP engine and how to maintain it. Excluding them from voting would be.. project suicide. > > The Foundation has no vote. The people who do half the work for PHP, who happen to work for the Foundation, have votes. As they should. > > > […] > > From the Foundation's home page: > > ``` > The PHP Foundation is a collective of people and organizations relying on the PHP language. Its mission is to ensure the long-term prosperity of the PHP language. > > The PHP Foundation focuses on providing financial support and guidance to PHP language developers to support its goals of improving the language for its users, providing high-quality maintenance, and improving the PHP language project to retain current contributors and to integrate new contributors. > > The PHP Foundation aims to promote the public image of the PHP language in the interest of retaining existing and gaining new users and contributors. > > Read our announcement for more details. > ``` > > That's what the Foundation does and is for. > > It really seems like you're inventing problems that do not exist, and have no bearing on the project itself creating working groups. That those WGs may overlap with the Foundation, both in goal and personnel, is a good thing in my mind. > > --Larry Garfield Hi Ben and Internals I agree this proposal. I'm glad that if this proposal is accepted. Please let me story that join in the php-src repo and this mailing list. So I spend many time (3-4 years?) because I don't know how to join this community. Therefore, Working groups can easy to access to this community from the world. I hope that people from all over the world who are interested will come. Regards Yuya -- --------------------------- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai --- ## #131321 — Ben Ramsey — 2026-06-16T13:40:18+00:00 URL: https://externals.io/message/131021#131321 · In reply to: #131271 > > […] > > > 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...? This RFC does not impose any restrictions or limitations on the PHP Foundation or its contractors. They're welcome to create and participate in working groups, and I never want to exclude them from voting on RFCs. I'm not sure what problem that would solve. > 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). This question doesn't seem related to the Working Groups RFC. The PHP Foundation is transparent about its role, and they are making efforts to be more transparent. As for the recent discussion about linking to X/Twitter, that had nothing to do with the foundation at all, so I'm not sure how you're making this connection. > 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. The Working Groups RFC is in no shape, way, or form an attempt to control how the PHP Foundation operates within the PHP community. I have zero problems with how they operate as an entity, and I trust their leadership. The WGs RFC exists to provide some (albeit loose) governance structure to the PHP Project without entirely up-ending the status quo. Cheers, Ben --- ## #131356 — Ben Ramsey — 2026-06-18T03:07:11+00:00 URL: https://externals.io/message/131021#131356 · In reply to: #131021 > I'm opening discussion on an RFC to create a policy for PHP project > working groups: > > https://wiki.php.net/rfc/working_groups I've made substantial changes to the Working Groups policy RFC that I'd like to call your attention to. I've moved the full text of the policy out of the RFC, replacing it with a simplified introduction and link to the policy pull request: https://github.com/php/policies/pull/35 Additionally, I've made the following changes to the policy text: * clarified that approved charters grant autonomy to operate within the scope of the charter without separate RFCs * added a section on PHP Project resources (VCS repositories, mailing lists) * specified that working group policies should be documented in the working group's repository rather than enumerated in its charter For more details, see the full diff here: https://github.com/php/policies/pull/35/changes/3d2d111504327a50fa7cddec54d021aff00c3063 Cheers, Ben --- ## #131725 — Ben Ramsey — 2026-07-02T22:44:43+00:00 URL: https://externals.io/message/131021#131725 · In reply to: #131356 > > > […] > > > I've made substantial changes to the Working Groups policy RFC that I'd > like to call your attention to. > > I've moved the full text of the policy out of the RFC, replacing it with > a simplified introduction and link to the policy pull request: > https://github.com/php/policies/pull/35 > > Additionally, I've made the following changes to the policy text: > > * clarified that approved charters grant autonomy to operate >   within the scope of the charter without separate RFCs > > * added a section on PHP Project resources (VCS repositories, >   mailing lists) > > * specified that working group policies should be documented >   in the working group's repository rather than enumerated in >   its charter > > For more details, see the full diff here: > https://github.com/php/policies/pull/35/ > changes/3d2d111504327a50fa7cddec54d021aff00c3063 There have been very few comments on this RFC, which makes it hard to gauge interest. I'd like to keep the discussion open a little longer before I open it for a vote (or withdraw it), so this is a gentle reminder to take a look and share any improvements or concerns you might have. Cheers, Ben --- ## #131727 — Pierre Joye — 2026-07-03T04:02:42+00:00 URL: https://externals.io/message/131021#131727 · In reply to: #131725 Hi Ben, > There have been very few comments on this RFC, which makes it hard to > gauge interest. I'd like to keep the discussion open a little longer > before I open it for a vote (or withdraw it), so this is a gentle > reminder to take a look and share any improvements or concerns you might > have. I suppose you saw it, but just in case, https://thephp.foundation/blog/2026/06/11/integrating-community-feedback-into-foundation-strategy-part2/ I can see some overlap here. And most likely to attract more external or internal persons than us here. Also I wonder why none of such announcements are also shared here, both to reach out members here and as transparency :) Cheers, -- Pierre @pierrejoye --- ## #131764 — Ben Ramsey — 2026-07-04T16:16:15+00:00 URL: https://externals.io/message/131021#131764 · In reply to: #131727 > Hi Ben, > > > > > […] > > I suppose you saw it, but just in case, > https://thephp.foundation/blog/2026/06/11/integrating-community-feedback-into-foundation-strategy-part2/ > > I can see some overlap here. And most likely to attract more external > or internal persons than us here. > > Also I wonder why none of such announcements are also shared here, > both to reach out members here and as transparency :) I've addressed the PHP Foundation SIGs in a couple of other messages in this discussion, but I've just updated the RFC with a dedicated section: https://wiki.php.net/rfc/working_groups#php_foundation_special_interest_groups_sigs Additionally, I've added a "Grant of Authority" section to the policy text: https://github.com/php/policies/pull/35/changes/888d93b56c7c2fdd99acb0cec3a6a526a4f74b89 I hope this clarifies the distinction between PHP WGs and PHP Foundation SIGs. Let me know if I can help further clarify. Cheers, Ben --- ## #131976 — Ben Ramsey — 2026-07-16T15:24:11+00:00 URL: https://externals.io/message/131021#131976 · In reply to: #131021 > I'm opening discussion on an RFC to create a policy for PHP project > working groups: > > https://wiki.php.net/rfc/working_groups Based on feedback over social media[1], I've added a "Charter RFC Discussion and Community Input" sub-section to the non-normative discussion section. This attempts to clarify and set expectations for discussion of charter RFCs. https://wiki.php.net/rfc/working_groups#charter_rfc_discussion_and_community_input Cheers, Ben [1]: https://phpc.social/@ramsey/116913238397733008