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

This is only part of a thread. view whole thread
  115782
August 23, 2021 22:57 tobias.nyholm@gmail.com (Tobias Nyholm)
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 <deleugyn@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
  115783
August 24, 2021 02:43 faizanakram99@gmail.com (Faizan Akram Dar)
On Tue, 24 Aug 2021, 4:27 am Tobias Nyholm, nyholm@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 <deleugyn@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.
  115787
August 24, 2021 11:26 deleugyn@gmail.com (Deleu)
> > 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. >
That would be a violation of voters rights. They are allowed to vote no without any reason whatsoever. Not having enough time to thoroughly discuss something or feeling like the RFC is being rushed due to feature freeze is a perfectly valid concern to vote No. I also disagree that 1 or 2 individual(s) (Release Managers) should hold power on influencing people's vote. On Tue, Aug 24, 2021 at 8:08 AM Pierre Joye php@gmail.com> wrote:
> Hi Marco, > > It is a very good text, thank you! > > It is also much needed, generally speaking. What I would add is about > what is allowed to begin with. I would rather restrict to fixes only. > > The other issue, which is the one Nicolas suffered from, incomplete > addition to begin with. Incomplete in the sense of, "We add feature A, > but behaviors A1 and A2 are not supported and can be done later". > > Best, > -- > Pierre > > @pierrejoye | http://www.libgd.org >
I believe that the concern you raise here would be categorized as outside the scope of what I intend to propose. The RFC process is in place to handle such cases. It may or may not need improvement, but the bottom line is that if enough voters agree with an RFC, even if everyone agrees that it is "incomplete" it's still an approved change for the language. A Refinement RFC policy would extend the time available to deal with implementation consequences found after the voting already took place, but ultimately would not really solve "incomplete" RFCs as perhaps completing an RFC might take an extra year or two. On Tue, Aug 24, 2021 at 4:43 AM Faizan Akram Dar <faizanakram99@gmail.com> wrote:
> Hi, > > I agree with Tobias. Such changes / requests are rare and require a > judgement call. >
While I don't disagree that exceptional processes are largely dependent on judgement calls, I don't think the proposal would largely step on such a matter. Taking the Nullable Intersection Type as an example, the author felt that the process was lacking in clarity. Another aspect that can be evaluated is that a Refinement RFC policy could allow shorter RFC periods due to it's limited scope, helping both RFC Authors and Release Managers to work within their deadline.
  115795
August 24, 2021 19:29 pollita@php.net (Sara Golemon)
On Mon, Aug 23, 2021 at 5:57 PM Tobias Nyholm nyholm@gmail.com>
wrote:

> > 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. > > Agreed, and I would say that we DO have a policy. The policy is that the
RMs make a judgement call in the moment. I still think the attributes syntax was appropriate to make an exception for (given it was a new feature and this would be our last chance to refine the syntax), as was the nullable intersections case (the additional change to the engine was trivial, while providing notable benefit). So I would say we don't need a strong policy saying "exceptions in these cases only". However, I'm all for some definitions of best practices and considerations to take into account to make the decision making process more predictable and less arbitrary. TL;DR - This RFC sounds like a great idea, assuming appropriately scoped. -Sara
  115829
August 25, 2021 18:51 ramsey@php.net (Ben Ramsey)
--OW50KTwN1QgL43wDSFzT6S1z2YZl2Fqvj
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Sara Golemon wrote on 8/24/21 14:29:
> Agreed, and I would say that we DO have a policy. The policy is that t= he
> RMs make a judgement call in the moment. I still think the attributes > syntax was appropriate to make an exception for (given it was a new fea= ture
> and this would be our last chance to refine the syntax), as was the > nullable intersections case (the additional change to the engine was > trivial, while providing notable benefit). So I would say we don't nee= d a
> strong policy saying "exceptions in these cases only".
Agreed. We already have a policy for this, and the RMs are empowered to make these decisions now. This RFC doesn't define anything new.
> However, I'm all for some definitions of best practices and considerati= ons
> to take into account to make the decision making process more predictab= le
> and less arbitrary.
I would be in favor of an "informational" RFC rather than a "policy" RFC. An informational RFC can define terms, such as "refinement RFC" and "feature freeze," without burdening the project with more policy overhead= =2E Cheers, Ben --OW50KTwN1QgL43wDSFzT6S1z2YZl2Fqvj--