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
