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

This is only part of a thread. view whole thread
  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--