On Tue, 24 Aug 2021, 4:27 am Tobias Nyholm, <tobias.nyh...@gmail.com> wrote:
> Thank you. > I appriciate you bring up this issue. > > Situations like this often requires a judgement call rather than something > that could be defined as a policy. > I suggest the release managers always should be in agreement before a RFC > is created during a “feature freeze”. If the release managers agree that a > change can be added, then the discussion and the vote should not consider > “if it is too late” or “this is rushed”. I think we can trust the release > managers to make the correct desiccation without an extra policy. > > // Tobias > > > On 23 Aug 2021, at 13:48, Deleu <deleu...@gmail.com> wrote: > > > > Hello everyone! > > > > We recently had the Nullable Intersection Types RFC process in an > > unconventional way starting a new RFC post feature freeze. If memory > serves > > me right, another similar incident happened with the Attributes RFC which > > had a syntax that could not be implemented without a secondary RFC [1] > and > > went through a secondary RFC which proposed a different syntax [2]. > > > > [1] https://wiki.php.net/rfc/namespaced_names_as_token > > [2] https://wiki.php.net/rfc/attributes_v2 > > > > I would like to gather opinion on a potential Policy RFC that would > define > > some guidelines for such a process. As Nikita pointed out [3], the > ability > > to refine new features is both important for the developer and > undocumented > > for the PHP Project. > > > > In order to not be empty-handed, I started a gist that can be seen as the > > starting point for this discussion, available at > > https://gist.github.com/deleugpn/9d0e285f13f0b4fdcfc1d650b20c3105. > > > > Generally speaking, I'm first looking for feedback on whether this is > > something that deserves attention and an RFC or is it so rare that it's > > fine to leave it unchanged. If there is interest in moving forward, I > would > > then also be interested in suggestions on things that should be > > included/excluded in the RFC. > > > > Marco Aurélio Deleu > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php Hi, I agree with Tobias. Such changes / requests are rare and require a judgement call. PS: Sorry if my email was posted twice, I replied via a different email which is not subscribed to internals list, so wasn't sure.