Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115798
MIME-Version: 1.0
References: <CADK1yXLZzoOjjNcpZ5ZtV9kSNgw4=SW9G74o26eLdAYV5cDzAQ@mail.gmail.com>
 <alpine.DEB.2.23.453.2108241825130.2773@singlemalt.home.derickrethans.nl>
 <CADK1yXL=HdA5jF9F09vAgvZYzDpxcuN-1vxudwmZ6BXkjtuPKg@mail.gmail.com>
 <C7EF7C8B-A617-4C44-AAD5-B970098EC5AB@php.net> <CADK1yXLuSkMmfBumC4y9g4oP5dP06jgcLeh6S8K57Lum_3i8wQ@mail.gmail.com>
 <48D54138-2930-4935-B979-9A9DE9B403F1@gmail.com>
In-Reply-To: <48D54138-2930-4935-B979-9A9DE9B403F1@gmail.com>
Date: Wed, 25 Aug 2021 00:24:54 +0200
Message-ID: <CADK1yXLr2rQJErt_uyPjfWLhRY3xAPEcNYJbEQ1ZDfs4=b4C0A@mail.gmail.com>
To: Tobias Nyholm <tobias.nyholm@gmail.com>, Sara Golemon <pollita@php.net>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007794a705ca559cbb"
Subject: Re: [PHP-DEV] Guidelines for RFC post feature-freeze
From: deleugyn@gmail.com (Deleu)

--0000000000007794a705ca559cbb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 24, 2021 at 10:15 PM Tobias Nyholm <tobias.nyholm@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=E2=80=99t trust the role of the Release Manage=
r. The
> timing of your RFC is also unfortunate assuming you don=E2=80=99t 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 <pollita@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.

--=20
Marco Aur=C3=A9lio Deleu

--0000000000007794a705ca559cbb--