Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115778
MIME-Version: 1.0
Date: Mon, 23 Aug 2021 22:48:39 +0200
Message-ID: <CADK1yXLZzoOjjNcpZ5ZtV9kSNgw4=SW9G74o26eLdAYV5cDzAQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000077ee6a05ca402623"
Subject: Guidelines for RFC post feature-freeze
From: deleugyn@gmail.com (Deleu)

--00000000000077ee6a05ca402623
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=C3=A9lio Deleu

--00000000000077ee6a05ca402623--