Re: [PHP-DEV] Guidelines for RFC post feature-freeze

This is only part of a thread. view whole thread
  115890
August 28, 2021 05:55 jordan.ledoux@gmail.com (Jordan LeDoux)
On Fri, Aug 27, 2021 at 11:11 AM Tobias Nyholm nyholm@gmail.com>
wrote:

> > But I do agree with you. The process would have been way better if they > said “no". Or if they clearly and unanimously said “yes” which would remove > focus on “it feels rushed” and “we can’t because of feature freeze”. > This is the the extended power I would like the RMs (as a group) to have. > > To be clear, Im not suggesting they should veto every RFC. Just changes > during feature freeze. Since RMs are experienced open source developers, Im > sure they know to ask for help privately whenever they need it. > > // Tobias >
I do not believe the reason people felt it was rushed is because of ambiguity from RMs. The reason people felt it was rushed is because: 1. It was a special case of combination types, which voters understood to be a feature targeting 8.2 2. Because it was a feature understood to be targeting 8.2, there was insufficient research into what was technically possible or favorable for general combination types. 3. Because it was a feature understood to be targeting 8.2, it had been specifically excluded from the intersection types RFC. None of those would have been addressed by anything from the RMs, because all of those have to do with the voters' understanding of what the roadmap is and what they had previously voted on. The people who had voted to include intersection types had very specifically been told that they were not nullable, and voted for it anyway, knowing that nullability would come when anticipated support for combination types came. This is my understanding of the situation, in any case. Jordan