Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128644
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Fri, 05 Sep 2025 11:58:33 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <e1a75f2c-f7c0-45ff-a9a9-12088df2e978@app.fastmail.com>
In-Reply-To: <0f32efec-b6c9-4ec0-96bf-297da722aaf1@bastelstu.be>
References: <53cdbf5b-7c6e-4ba1-9987-332634cab527@bastelstu.be>
 <4624748F-0C62-4E3C-81D0-5CDC56FEC55F@nicksdot.dev>
 <c177c3340f458a4de58fefb4107c1753@bastelstu.be>
 <dd1e34df1b5b740948ab24f0b4bd367b@bastelstu.be>
 <68c44ae3-8e1b-419d-9c30-906b9c2d5a81@app.fastmail.com>
 <0f32efec-b6c9-4ec0-96bf-297da722aaf1@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 4:09 PM, Tim D=C3=BCsterhus wrote:

>> The language for the "extending the discussion period" paragraph is h=
ighly clumsy and confusing.  The existence of the last sentence to clari=
fy it is evidence of that.  I would recommend rewriting it.  (I can offe=
r suggestions if you're open to it.)
>
> I am open to suggestions, yes. Not being a native speaker makes it eas=
y=20
> to write stuff that makes sense to me, but are confusing to folks that=20
> actually understand the language :-)
>
>> Really, though...  what is actually being proposed, and is not actual=
ly a widespread convention right now, is a policy of "the vote may start=
 two weeks after the last substantive change."  For some definition of "=
substantive."  If that is the intent, it should just say that.  And we s=
hould discuss directly if we actually want that requirement.
>
> That would be an accurate summary of what that part of the policy is=20
> trying to codify, yes.

Proposed language, to turn the whole thing around:

-----

An RFC author MAY start a vote at any time, provided that:

* It has been at least two weeks since the last major change.
* It has been at least one week since the last minor change.
* There has been at least one post of any kind in the discussion thread =
within the last 6 weeks.
* The author has posted an intent to open the vote at least 48 hours pri=
or.  (This post is the only one that does not count toward the "last 6 w=
eeks" rule.)
* There is no ongoing relevant and substantive discussion still happenin=
g in the thread.  The author may determine what qualifies as relevant an=
d substantive, but SHOULD be liberal in interpreting that.

-----

(The final point is to help avoid the hecklers veto problem.  If people =
are just talking in circles, or there's a tangent discussion still going=
 that doesn't matter to this RFC, those shouldn't count.

I am also still not 100% convinced this level of formal-time-extension i=
s necessary.  There are always RFCs introduced late in the cycle that ru=
n up into freeze.  That will happen no matter what we do; they may even =
be going for a few months before getting there.  But if consensus is fin=
ally reached 13 days before the last day to start a vote to make the fre=
eze deadline, and everyone seemingly agrees with the final change, it se=
ems silly to say "whelp, sorry, you should have posted the last update 1=
2 hours earlier, now we all have to wait an extra year for the thing we =
finally agreed on."

> And I would say that this matches the lived reality: For most=20
> (successful) RFCs the author makes some changes, announces them on the=20
> list and then ask for feedback (e.g. from the person who originally=20
> suggested the changes or who pointed out the mistake), which can easil=
y=20
> take a day or two to arrive. This then often sparks additional=20
> discussion that takes a few more days to settle down due to varying=20
> schedules and timezones. At this point a week easily passed.
>
> I would also say that it matches the spirit of a =E2=80=9Cminimum disc=
ussion=20
> period=E2=80=9D. It does not appear very useful that it is technically=
 allowed=20
> by policy to replace the entire RFC text 10 minutes before the vote.=20
> Something something RFC of Theseus.
>
> In cases where the actual proposal (rather than e.g. the examples)=20
> repeatedly changes over the course of the discussion generally indicat=
es=20
> some severe problem or oversight with the RFC. It would often be more=20
> appropriate for the RFC author to go back to the drawing board,=20
> consulting with some close advisors to figure out how to fix these=20
> problems rather than discussing all those details on the list.

That often happens, but then the revisions are put forward in the same t=
hread.  That's process-wise identical.


> That section is intentionally using the =E2=80=9CSHOULD NOT=E2=80=9D i=
ndicator, to avoid=20
> folks being able to filibuster an RFC. It also intentionally used the=20
> word =E2=80=9Cnew=E2=80=9D in front of =E2=80=9Cdiscussion points=E2=80=
=9D to indicate that repeating=20
> something from before (something that most likely already was rejected=20
> by the RFC author) does not constitute a new discussion point. The=20
> intention is to encourage RFC authors to give suggestions sufficient=20
> deliberation (and ideally a response), even if it comes in after the=20
> voting announcement.
>
> I'm happy to rephrase if you have any suggestions.

I believe my bullet point list above encapsulates this expectation.

Regarding the time precision debate elsewhere in the thread: For most th=
ings, I don't think we need to get hung up on exact timing.  If it's bee=
n 6 days, 23 hours, and 49 minutes since the last update to an RFC, and =
there's been no discussion in that time, and the last post was everyone =
agreeing that the last change is good...  Then it's kinda stupid to get =
hung up on "you didn't wait exactly 11 minutes" and invalidate a vote th=
at is clearly ready.  If we were a more protocol-and-process oriented pr=
oject with actual leadership, then more precision might make sense.  But=
 PHP is not that, for better or worse: It's a bunch of people arguing an=
d coming to rough consensus in the messiest way possible.  Fussing about=
 a minute here or there is not helpful.

The one place I think it would matter is when the vote closes, since tha=
t's a hard-cutoff for someone to vote or change a vote.  For that, IMO t=
he best solution is technical: Update the voting widget to both have an =
auto-close time, and show the start and auto-close time on the wiki page=
.  The vote closes when the widget says it does.  Presumably it would be=
 easy for it to default to the exact same time as the start stamp, and t=
hen... I don't care about leap seconds or daylight savings time.  It end=
s in ~2 weeks, automatically, and the exact time is right there on the p=
age.  Plan accordingly.

Then all the faffing about with date-and-time edge cases goes away and w=
e can move on with life.

--Larry Garfield