On Tue, Aug 24, 2021 at 10:15 PM Tobias Nyholm <tobias.nyh...@gmail.com> wrote:
> Hey Marco. > > The fact that you unprompted (as far as I can tell) decided to in detail > specify how RMs should make their decision about an RFC is giving me a > strong signal that you don’t trust the role of the Release Manager. The > timing of your RFC is also unfortunate assuming you don’t want to imply > they are doing a poor job as they just got some criticism in a different > thread. > > I may be wrong and the current and previous release managers feel like > they really need another policy dictating their work, if so I really hope > you worked with a few of them while you drafted this RFC. > > > // Tobias I have updated the gist to include a Motivation section that attempts to shed a bit more light into what the general idea is. If there is anything in the text of the RFC that validates your perception to the RFC, I would be interested in changing that. As for your perception, I would like to make an attempt to clarify my perspective in the hopes of easing some of these concerns. Timing: I feel like proposing a policy change when it isn't clear why such a proposal is being made is actually worse as it is not clear why such a proposal would be made. I believe timing works in favour of the RFC because people may be more receptive to perceiving that amending the guidelines could have made recent events smoother for people involved. Implying a poor job from Release Managers: As I stated on the Nullable Intersection thread, I don't feel like there was any misconduct or poor handling of the process. In fact, the text I drafted for this RFC simply reinforced everything that was already done: RMs can grant permission for a Refinement RFC and can rescind it. Other release managers would be able to see stated on the RFC that a grant was given. Dictating Release Managers work: The text does not attempt to do that either. It just explicitly empowers Release Managers and instructs RFC Authors how to present a Refinement RFC. Working with Release Managers: I'm a novice in the PHP Project and I don't feel comfortable bothering anybody personally. This thread doesn't even represent the official RFC discussion, it just follows the item 1) of How to Propose a RFC [1]: "Email internals@lists.php.net to measure reaction to your intended proposal." As such, I feel like I'm properly following the guidelines on how to propose an RFC by measuring the reaction of internals about my proposal. Unprompted: As I sadly failed to link on the first email, Nikita has made a comment about whether the process should be a bit more flexible when trying to implement approved RFCs [2]. I saw an opportunity to pick up the work on that and I just did. Part of my motivation is to empower core developers to bring Refinement RFCs whenever they're struggling to land an implementation that suddenly presents challenges that were hidden such as how the Attribute syntax was ambiguous after it had been approved. If I failed to address any of your concerns, I'm happy to try again and I want to reinforce that if you can link any of these concerns you raised to the text of the RFC, I really want to change the text. As an author of a Policy RFC, I want to be absolutely sure that nobody in the future would read the text and feel like the policy is dictating how Release Managers should work. [1] https://wiki.php.net/rfc/howto [2] https://externals.io/message/115700#115753 On Tue, Aug 24, 2021 at 9:30 PM Sara Golemon <poll...@php.net> wrote: > TL;DR - This RFC sounds like a great idea, assuming appropriately scoped. > > -Sara > That's wonderful to read! I'm looking forward to refining the scope as necessary. One question I have for experienced release managers is whether clause 11 is good/bad and whether it should mention a specific number of days or leave it open for judgement calls. -- Marco Aurélio Deleu
