On Fri, Jan 23, 2026, at 6:04 AM, Edmond Dantes wrote: > Hello. > >> I don’t think that’s universally true, or at least it hasn’t been my >> experience. > As far as I know, there is no universal truth. PHP plus asynchronicity > plus a crisis of trust is a very specific situation. > And it has existed longer than this RFC. It’s a fairly large topic for > discussion, and probably uncomfortable. > >> When I personally stepped back > Lately, I’ve been hearing the phrase “take a step back” quite a few times. > But believe me, not a single person who’s said this to me has been > able to clearly explain what they actually mean. > What does “a step back” even mean? > >> I want to be clear about something important, though: this isn’t a lack of >> interest in asynchronous capabilities in PHP, nor a lack of willingness to >> help. > > * Python got asynchronicity in 2015. > * Python is a general-purpose language, and asynchronous I/O is not a > critical feature for it. > * PHP still hasn’t gained asynchronicity. It’s 2026. > * For PHP, asynchronicity matters more than it does for Python. > > On top of that, there have been some attempts by different people to > add asynchronicity to PHP, all of which either failed or were ignored. > So there is interest in asynchronicity, but it seems to be buried > very, very deep :) > >> contributors need to feel that concerns are being heard, trade-offs are >> being explored together, and iteration is genuinely collaborative. > > * What concerns? > * What collaboration? > What is this actually about? > > Everyone who wanted to collaborate on this RFC has already done so. > I’m running this project 100% openly, there isn’t even a private chat. > Only a few ideas were discussed privately over email, and I always > write about the outcomes of those discussions publicly. > >> If the process moves in that direction, breaking things down, explicitly >> engaging with criticism, and evolving the design based on shared input, I >> think you may find that more people are willing to invest time and energy >> into it. > > Sorry, but I don’t understand anything from this sentence at all: > * Which direction? What’s wrong with the current one? > * Into what parts should things be broken down, and why? > * What does “explicitly engaging with criticism” mean? And what kind > of work was being done before. Implicit? Hidden? > * What does “evolving the design based on shared input” mean? Who is > stopping you from contributing to an open repository? Who is this > person who is forbidding it? Tell us who they are and we’ll punish > them :) > > And you seem to be missing the most important point: > * this project is not something I personally need. > * It’s not my project that people aren’t joining. > * The TrueAsync project was created first and foremost for PHP itself. > * PHP is the one that needs it. > > I am already an experienced and fully capable developer without it. I > don’t need to prove anything to anyone. > The problems with the process of accepting large changes to the > language cannot be solved by me. They are outside the scope of my > responsibility. > I don’t need to solve it. I don’t need to create working groups. I > don’t need to write private emails and ask everyone to vote. I’ve > already done the work within the scope of the responsibility. > > The remaining percentage of success no longer depends on my actions.
I've not had a chance to look at the latest draft yet, but I do want to speak to the process debate. There's multiple overlapping problems/challenges here, and we need to separate them. 1. This proposal is *huge*, and subsequent drafts are often very heavily modified, so that means people need to spend an hour or two each time there's a change fully digesting it. That's a very large ask, especially when there are exactly 0 people in the world who have "review RFCs" as their job description; not even the Foundation team has that, technically. I've worked on some very large RFCs (hooks), so I know the challenge this poses, but Async is even worse because it's more conceptually complex and far reaching. This is exacerbated by, I suspect, a language barrier issue, which comes off as Ed being dismissive of feedback. But regardless of the cause, there are definitely people who feel their concerns have been dismissed (rightly or wrongly). I know I spent many hours reading and responding to earlier drafts a year ago, and I know some of that feedback still hasn't been incorporated. 2. Because it's so complex, we get a strong reverse-bikeshed problem. This is a nuclear-reactor level feature, not a bikeshed level feature, so fairly few people even feel qualified to critique the specifics, whether they have the time to or not. 3. PHP is a structureless organization. That means we suffer from the Tyranny of Structurelessness[1]. (Please everyone, do read that article. It takes less time than reading the Async RFC. :-) ) It's not that PHP has no leadership, it's that the leadership is an informal amorphous blob with no clear definition, and everyone has a different idea of who it is. 8 years ago, there was a de facto consensus that Nikita was The Lead(tm), and so if Nikita liked something it would probably pass because people trusted Nikita, and if Nikita didn't like something it would probably not pass because people trusted Nikita. Nikita was a known quantity, and people trusted his judgement, even if they didn't always understand it. So Nikita's RFCs almost always passed. (Whether you consider that good or bad is a separate matter.) Today, there's about a half dozen people that have maybe a quarter of that clout. Of course, there's no consensus on exactly who those people are. It probably overlaps heavily with the Foundation staff, but not entirely. But that means there's no one who can "bless" this RFC to give everyone else confidence that the adults in the room, the PHP elites if you will, think it's OK. That's what's really missing from this RFC: Quite simply, Ed is an unknown quantity. This is his first RFC, and it's a doozy. If the exact same RFC were proposed by, for example, a team of Ilija, Arnaud, Tim, and Derick, it would likely get a much warmer reception and attention. Not because those people are "better developers" than Ed, but because they have a track record, cloud, and "street cred" that Ed simply does not. Naturally, your list of who has that kind of "cloud" will be different from mine; that is the problem of a structureless organization. If Ed had been partnering with one of those "elites" all along, or brought one in part way through to vet and approve things, the RFC itself would probably be stronger but also more palatable. *That* is what the various requests for a working group were about. Not "go elsewhere and talk to a bunch of people who never post on the Internals list to get their buy-in." That may be technically useful (and it seems like it was), but it's not politically or socially useful. What is lacking is "the people who are visible in Internals that I trust to sweat the details are on the job, and they're on board, so I feel safe being on board." To be clear: This is not in any way shape or form Ed's fault. This is 1000% a failure of PHP the project, and a direct consequence of the project's steadfast refusal to introduce any sort of meaningful formal structure. This is why some of us have been trying on and off for years to fix this problem, but so far unsuccessfully. What is really needed here, frankly, is for there to be more names on the RFC, and more familiar names. People who have the "street cred" to be trusted, or that we know how to engage with. People who are able to form consensus. That's what a working group means in this case: Having clear, dedicated, influential input into the design from people, both generalists and specialists, that others will trust to "get it right.." Who those people should be, well, we're a structureless organization so I'm pretty sure everyone has a different list of names. [1] https://www.jofreeman.com/joreen/tyranny.htm --Larry Garfield
