Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102708
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.208.46 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
Date: Tue, 10 Jul 2018 09:10:40 -0400
Message-ID: <CAESVnVoRW7kovTAPPqb1PBbrabtbwR==ZW8QSGoeFWBzS68-sQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: On not rushing things at the last minute
From: pollita@php.net (Sara Golemon)

I'm disappointed by the last minute kitchen-sink dump of RFCs being
raised, rushed through discussion, and voted on with minimal periods.
While I'm all for delivering useful features to end users, I don't
want us to get in the habit of seeing months of quiet followed by
weeks of chaos every year around this time.  This isn't even new,
though it seems like it's becoming more commonplace with the adoption
of the yearly cadence.

What are the causes?

Is it seasonal? Some people have more time during the summer because
of school/family schedules?  Maybe the solution is to shift the
release window a few months in one direction or the other.

Is it failing to get our shit together?  Maybe we should discourage
late RFCs by requiring a higher voting threshold?  e.g. You can open
voting as ridiculously late as a week before feature freeze (honestly,
who would do that?) if you want, but you'll need an extra 10% to pass
on top of whichever threshold already applies.

We don't need to solve this now, this week, because there are plenty
of rushed, last-minute proposals on the table already.  But I'd like
folks to start thinking about this and ways we can mitigate this
problem come future releases.

-Sara