Re: Guidelines for RFC post feature-freeze

On Wed, Aug 25, 2021 at 10:25 PM Ben Ramsey <ramsey@php.net> wrote: > Deleu wrote on 8/24/21 13:53: > > The proposal is rooted in making it easier for release managers and rfc > > authors to refine code changes that may or may not be necessary to > > accomplish a previously approved RFC. > > I don't understand how this proposal helps with this. If changes are > necessary to accomplish a previously approved RFC, that means the RFC > isn't fully implemented, so there are bugs, and bugs should be addressed > using the normal bugfix process. They shouldn't require another RFC. > > If a change requires another RFC, that means something is being proposed > that changes the behavior of a previous RFC (or adds to it). This is a > new feature. > > Cheers, > Ben > > This is where looking at the Attribute RFC may be helpful. The approved syntax was actually ambiguous and only discovered during implementation. A secondary RFC to change the syntax was proposed. Was this secondary RFC a new feature? Not exactly. Was it a bugfix? Not exactly either. The point of a Refinement RFC is an attempt to address what Nikita said on the other thread: > As a meta note, I think it's important that we're open to minor changes to > new features during the pre-release phase -- it's purpose is not just > implementation stability. In fact, we can fix implementation bugs anytime, > but usually can't do the same with design issues. Some design issues might require changes that are not necessarily a new feature, but it's not a bug either. They may be able to be implemented as-is, but is that the best decision for the project? Again, let me state that whether Nullable Intersection Types is a new feature or not is beyond the scope of this proposal. That is something for Release Managers to evaluate and voters to decide. These guidelines help in establishing a process to deal with design issues during implementation of already-approved RFCs in a timely manner. -- Marco Aurélio Deleu