Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128212
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 24 Jul 2025 08:46:11 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <73dc33a9-66fa-4ef3-832a-6a0c1d0387ec@app.fastmail.com>
In-Reply-To: <a86ad6b0cf021170678f466e2f34e9a8@bastelstu.be>
References: <b0d97beef95862524b329922522bbefe@bastelstu.be>
 <26c4161a-1520-4134-8fc1-74dc4a27c463@heigl.org>
 <CAMzRQTfVM=uOvA7-3CHV6AcO-Y-xPJV5QuSEueFO1iohMFdhKg@mail.gmail.com>
 <fc9c244b-38f5-4ced-9062-29d3609f73c9@heigl.org>
 <a86ad6b0cf021170678f466e2f34e9a8@bastelstu.be>
Subject: Re: [PHP-DEV] [RFC] "Abstain" voting option for RFCs
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Jul 24, 2025, at 4:28 AM, Tim D=C3=BCsterhus wrote:
> Hi
>
> Am 2025-07-23 17:34, schrieb Andreas Heigl:
>> As you point out, the abstain alone solves a me "problem". Changing t=
he=20
>> process just for that, seems overkill to me.
>
> Requiring an "Abstain" option in the voting widget is a simple change =
to=20
> the process. It does not require any additional effort from RFC author=
s,=20
> since I'll make sure to add it to the voting widget in the RFC templat=
e=20
> (https://wiki.php.net/rfc/template) should this RFC pass.
>
> I believe the proposal has sufficient merit on its own and also allows=20
> us to collect "hard data" that can be used as part of a discussion for=20
> future scope changes, such as an RFC quorum.
>
> I don't believe having an "Abstain" option needs to be tied to larger=20
> changes to the process and I am not interested in increasing the scope=20
> of this RFC, intentionally leaving those to =E2=80=9CFuture Scope=E2=80=
=9D. If you don't=20
> see the value right now, but don't outright reject the proposal due to=20
> being interested in future scope changes building on the proposal,=20
> abstaining from the vote would probably be the right decision :-)
>
> Best regards
> Tim D=C3=BCsterhus

Applying similar logic as for technical RFCs,=20

* This is self-contained.
* This dove-tails cleanly with planned and intended future development.
* Adopting it now does not preclude those future developments, nor do an=
y harm to the language/process on its own.
* The order in which those related developments are adopted (eg, a quoru=
m, or a "use it or lose it" policy, etc.) does not matter.  If anything,=
 it would make more sense for Abstain to come first, rather than after t=
hose.
* This one is largely uncontroversial, whereas a quorum or "use it or lo=
se it" policy almost certainly would be.

Those all strike me as good reasons this is fine to adopt stand-alone an=
d get it out of the way, just as, eg, pipes could be adopted without PFA=
, on the expectation of PFA later.

--Larry Garfield