Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128615
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Wed, 03 Sep 2025 15:07:48 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <68c44ae3-8e1b-419d-9c30-906b9c2d5a81@app.fastmail.com>
In-Reply-To: <dd1e34df1b5b740948ab24f0b4bd367b@bastelstu.be>
References: <53cdbf5b-7c6e-4ba1-9987-332634cab527@bastelstu.be>
 <4624748F-0C62-4E3C-81D0-5CDC56FEC55F@nicksdot.dev>
 <c177c3340f458a4de58fefb4107c1753@bastelstu.be>
 <dd1e34df1b5b740948ab24f0b4bd367b@bastelstu.be>
Subject: Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Sep 3, 2025, at 8:25 AM, Tim D=C3=BCsterhus wrote:
> Hi
>
> Am 2025-09-02 15:08, schrieb Tim D=C3=BCsterhus:
>>> 1) Reference of discussion in RFCs
>>>=20
>>> When I try to look into the discussions of older RFCs to find out wh=
y=20
>>> they ended up the way they did, it=E2=80=99s not easy. You hardly ca=
n find=20
>>> them. This is because they are often not referenced in the RFC itsel=
f.
>>>=20
>>> Going forward, would it make sense to make it mandatory to reference=20
>>> '[Discussion]' and '[Vote]' in the RFC text itself?
>>=20
>> I'll make the requested adjustments and then follow up here on the=20
>> list.
>
> I have made the change in the following commit:=20
> https://github.com/php/policies/pull/23/commits/fdd28a322aa03ccc822d8f=
0ac3fa1d934a519a7e,=20
> added the link to the discussion of this very RFC to the RFC itself an=
d=20
> updated the changelog section. As this is a major change to the RFC,=20
> the=20
> discussion period will go for another 2 weeks from now.
>
> Given that the emails do not immediately become available in the=20
> archives, I've used the =E2=80=9Cas soon as possible wording=E2=80=9D =
with deadline for=20
> the voting announcement and voting close respectively. While the RFC i=
s=20
> in progress, the threads should still be easy to find. The goal is to=20
> preserve easy access after several months have passed, so I don't thin=
k=20
> a super tight deadline is necessary as long as it happens eventually.

"If the proposal
is a repeated discussion of an existing RFC, with or without modificatio=
n, it
MUST still be announced on the list for discussion."

What does "repeated discussion" mean?  Is that "I've taken over this old=
 RFC and revised it", or "no one has commented on this RFC in the last m=
onth so now it has to be a new thread" or "I'm saying things that have a=
lready been said because I didn't read the list yet"?

-----

The language for the "extending the discussion period" paragraph is high=
ly clumsy and confusing.  The existence of the last sentence to clarify =
it is evidence of that.  I would recommend rewriting it.  (I can offer s=
uggestions if you're open to it.)

Really, though...  what is actually being proposed, and is not actually =
a widespread convention right now, is a policy of "the vote may start tw=
o weeks after the last substantive change."  For some definition of "sub=
stantive."  If that is the intent, it should just say that.  And we shou=
ld discuss directly if we actually want that requirement.

-----

" Minor changes to the RFC text include adding new examples, updating
existing examples, adding additional explanation or clarification, or an=
y other
changes that are not purely editorial."

We must be working with different definitions of "editorial", because th=
ose seem editorial to me. =20

-----

"Similarly RFC authors
SHOULD NOT proceed with an announced vote if new discussion points are b=
rought
forward after the voting announcement."

Any discussion point, or valid discussion points?  For some definition o=
f valid?  This seems like an easily exploitable way to "hecklers veto" a=
n RFC by never letting it go to a vote by just talking too much.  As a c=
oncrete example, and not to pick on her but it's the first to come to mi=
nd, Juliette had a long response to the Property Hooks thread that came =
in a day before voting was to start, after multiple months of discussion=
.  It didn't really add anything *new* to the discussion; it didn't poin=
t out any bugs in the design, just general unease with its extensiveness=
.  Should that comment force a delay in the vote by its simple existence=
?  I firmly think not. =20

I would recommend at least adding "if new relevant discussion points are=
 brought forward".  Where "relevant" is at the RFC author's good faith j=
udgement.  However, some discussions just go around and around at length=
 but go nowhere.  The author should be able to put a pin in it and say "=
'nuf said, we're voting, that will resolve this question, vote no if you=
 are on team X."  Otherwise, again, we just keep talking forever.

-----

I can easily see a mostly-run-its-course discussion thread that would be=
 ready for a vote in early December, but that would then run into the ho=
liday blackout period, so the authors delay the vote until mid-January. =
 (I'm pretty sure I've done that before.)  However, that could run into =
the 6-week fallow rule proposal.  Should there be any sort of allowance =
for that, so that the mandatory blackout period doesn't force delaying a=
n RFC even more?

--Larry Garfield