Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128656
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Mon, 08 Sep 2025 10:14:09 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <c252a4ef-f9da-423e-92b4-4babbbc336bb@app.fastmail.com>
In-Reply-To: <4b809fc105b2cb53992dedde44cf6bc8@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>
 <e1a75f2c-f7c0-45ff-a9a9-12088df2e978@app.fastmail.com>
 <4b809fc105b2cb53992dedde44cf6bc8@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 Mon, Sep 8, 2025, at 9:20 AM, Tim D=C3=BCsterhus wrote:
> Hi
>
> Am 2025-09-05 18:58, schrieb Larry Garfield:
>> Proposed language, to turn the whole thing around:
>>=20
>> -----
>>=20
>> An RFC author MAY start a vote at any time, provided that:
>>=20
>> * 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 thre=
ad=20
>> within the last 6 weeks.
>> * The author has posted an intent to open the vote at least 48 hours=20
>> prior.  (This post is the only one that does not count toward the "la=
st=20
>> 6 weeks" rule.)
>> * There is no ongoing relevant and substantive discussion still=20
>> happening in the thread.  The author may determine what qualifies as=20
>> relevant and substantive, but SHOULD be liberal in interpreting that.
>>=20
>> -----
>
> Thank you. That would likely require breaking up the existing structur=
e=20
> oh =E2=80=9CDiscussion Phase=E2=80=9D and =E2=80=9CVoting Phase=E2=80=9D=
 a little to incorporate this=20
> cleanly. It would basically make the entire =E2=80=9CDiscussion Phase=E2=
=80=9D section=20
> obsolete, which is quite large of a change that I'll need to think abo=
ut=20
> a little more.
>
> Perhaps the latest changes already make the language a little less=20
> awkward?

It's an improvement, but I think it can still be improved further.  It's=
 still very verbose, and not in ways that I feel are necessary.

Would you be OK with me PR-ing a restructure to try and clarify further,=
 including the text above?

(I used to be the documentation lead for a former employer, was a journa=
list for a few years, and wrote most of the bylaws for FIG.  I think I'm=
 reasonably good with words.)

>> (The final point is to help avoid the hecklers veto problem.  If peop=
le=20
>> are just talking in circles, or there's a tangent discussion still=20
>> going that doesn't matter to this RFC, those shouldn't count.
>
> I have just incorporated a suggestion from Ilija to soften the languag=
e=20
> a little:=20
> https://github.com/php/policies/pull/23/commits/2d022476e647ab12ac7816=
73597fec2ad87cba82
>
>> I am also still not 100% convinced this level of formal-time-extensio=
n=20
>> is necessary.  There are always RFCs introduced late in the cycle tha=
t=20
>> run up into freeze.  That will happen no matter what we do; they may=20
>> even be going for a few months before getting there.  But if consensu=
s=20
>> is finally reached 13 days before the last day to start a vote to mak=
e=20
>> the freeze deadline, and everyone seemingly agrees with the final=20
>> change, it seems silly to say "whelp, sorry, you should have posted t=
he=20
>> last update 12 hours earlier, now we all have to wait an extra year f=
or=20
>> the thing we finally agreed on."
>
> I believe a clear and objectively measurable rules are necessary to=20
> treat everyone fairly. If 13.5 days are acceptable, are 13 days also=20
> acceptable? What about 12.5 days? Where do we draw the line?

As I said elsewhere, if we were an organization with that level of forma=
lity and structure, I'd likely agree.  But this project has actively rej=
ected even a modicum of structure or "enforcement" ability, so it seems =
incongruous to have highly pedantic scheduling but loosey-goosey everyth=
ing else.

>> The one place I think it would matter is when the vote closes, since=20
>> that's a hard-cutoff for someone to vote or change a vote.  For that,=20
>> IMO the best solution is technical: Update the voting widget to both=20
>> have an auto-close time, and show the start and auto-close time on th=
e=20
>> wiki page.  The vote closes when the widget says it does.  Presumably=20
>> it would be easy for it to default to the exact same time as the star=
t=20
>> stamp, and then... I don't care about leap seconds or daylight saving=
s=20
>> time.  It ends in ~2 weeks, automatically, and the exact time is righ=
t=20
>> there on the page.  Plan accordingly.
>
> The voting widget already has support for an automated closing (an=20
> example is in the template). But it would certainly make sense to also=20
> show that within the widget itself. I'll see if I can send a PR to do=20
> that. I still believe that formalizing when the vote may *start* makes=20
> sense. And of course, the RFC author needs to accurately calculate the=20
> end date still. Personally I just round to the next half hour to be we=
ll=20
> over 2 weeks and to get a nice round time. I've seen others simply use=20
> the next UTC midnight after 14 days.
>
> Best regards
> Tim D=C3=BCsterhus

I would strongly recommend we make using the auto-closer mandatory, then=
.  I don't think I've ever used it as I didn't know it was available, bu=
t I'd much rather we all use that and simplify things.

Also, I think this is new:

> If issues with an accepted RFC are noticed during implementation, an e=
rrata
section explaining the necessary changes SHOULD be added.

We should include guidance on what level of changes are acceptable and w=
hich would require a new RFC, or even possibly unaccepting an RFC.

As examples:

1. Attributes went through 2-3 extra votes to fiddle with the syntax aft=
er the initial RFC.
2. Hooks had a follow-up RFC to approve a non-syntax change to error han=
dling, in the name of performance.
3. Pipes had a non-RFC syntax change to handle the unexpected parsing is=
sue with arrow functions.

I'd argue that #3 was a larger change than #2, yet #2 had an RFC and #3 =
we decided did not need one.  (Not suggesting any of the above was wrong=
, they're just examples to show we're not currently consistent.)

I would recommend we give this decision-making to the RMs.  If a change =
needs to be made post-vote, the RMs are empowered to decide if it needs =
a follow-up RFC, follow-up informal discussion, or "just do it, it's fin=
e."  (All of the above should still be included in Errata, of course.)

--Larry Garfield