Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104066
To: internals@lists.php.net
Date: Sun, 03 Feb 2019 11:05:10 -0600
Message-ID: <5102639.xMBIVU9WTp@vulcan>
In-Reply-To: <CAF+90c_PrC7M9=R83O3W2Q3NJRCNAcuzX2yemuaB6ub6hUACzw@mail.gmail.com>
References: <CAF+90c-auGYVhCzt-1GpdU1-uZ+xiY7A_FwWSRKftuKBwtszYg@mail.gmail.com> <04a401d4bb7f$eb879900$c296cb00$@gmail.com> <CAF+90c_PrC7M9=R83O3W2Q3NJRCNAcuzX2yemuaB6ub6hUACzw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart4193605.IMr3qAAT9y"; micalg="pgp-sha512"; protocol="application/pgp-signature"
Subject: Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
From: larry@garfieldtech.com (Larry Garfield)

--nextPart4193605.IMr3qAAT9y
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Sunday, February 3, 2019 4:07:46 AM CST Nikita Popov wrote:
> On Sun, Feb 3, 2019 at 6:18 AM Zeev Suraski <vsuraski@gmail.com> wrote:

> > The suggestion that the new RFC makes life more difficult, compared to the
> > current Voting RFC, is simply wrong.  It is, in fact, very much the same -
> > except it's a lot more well defined in terms of 'what happens if' - which
> > in the years since the 2011 Voting RFC was enacted became a de-facto
> > wild-west.
> 
> As quite likely the single largest user of the RFC process, I beg to
> differ. I think your perspective here comes about, because your use of the
> RFC process is limited to rare, but large (in the sense of important)
> proposals. However, that's not the case for all or even most RFCs. It is
> already the case that RFCs are cumbersome for smaller changes, and all
> active contributors I know (apart from cmb maybe) will go out of their way
> to avoid going through the RFC process if it is at all avoidable. It is
> something of a social faux pas to tell another core contributor on a PR
> that their change might benefit from an RFC, because that generally means
> that the change will be dropped dead in the water instead.
> 
> I think that we *should* encourage the use of RFCs for less significant
> changes, because it is useful to have design considerations spelled out in
> more detail than a two line commit message. Your proposal does not make
> things much more complicated, and doesn't make the RFC process take much
> more time. But it increases the marginal costs just enough to make RFCs
> even more annoying than they already are. You edit your proposal a few
> times at inopportune moments and bam, you have to wait one and a half
> months before it can land. That's okay if you're trying to introduce a JIT
> in PHP, but if you just want to add a function, that's the point where you
> say "Why do I even bother with this?"
> 
> Regards,
> Nikita

If I may, it seems like the intended goal is to ensure that a proposal gets 
"enough" attention, "enough" time for people with other priorities to find, 
read, digest, and decide on it, and to avoid last minute changes in the RFC so 
that people don't fully realize what they're voting on (for some definition of 
"enough").

To that end, what about simply a "fallow period" before a vote can be called?  
To wit:

"Once an RFC has been announced, the proposal may call a vote on it at any 
time provided that there have been no substantive changes within the past 2 
weeks.  If there is reasonable dispute over whether a change is 'substantive', 
then it is assumed to be substantive."

That assures that there is always at least a 2 week discussion period, but you 
could still go from proposal to vote in 2 weeks.  It also ensures that if 
you've read an RFC in the last 2 weeks when the vote is called that you're 
still up to date.  However, minor changes (wording, revising an argument for 
something but not changing the actual thing, etc.) don't cause an RFC to sit 
in limbo for months.  Of course, if the RFC is still changing regularly then 
that would continue to kick the voting period further down the line, which is 
what you want in that case since it's still being revised.

It also has the advantage of being really short and easy to grok.  

--Larry Garfield
--nextPart4193605.IMr3qAAT9y
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEE/ph/GXfY8v0YwFBp4MMKwDFxYXcFAlxXH0YACgkQ4MMKwDFx
YXeN7QgA5XglZ1kfM7mymMqmBisO+PQnkDSShc0i9ZqImHwiI6vF5NqCuBTxQ4Ly
cfG/EMYFq1c+xZStn+tyECAU9mVewuTTvxnb74nPLOsAOaVr4FYicUzy0LTIhqDj
SBmRJgrhGaTjCnS9lAqtUqP2JZ3FR0HtayDi9xEivUZmkuzcUNe8006PxqIdlSR/
aq1rl7R+EyC8HnNX9vwmUIPdIc+kwWlhpCY7IE99GMPbQnAboDTn3u+M21IM+YFC
AYu7+0l8L0EF/z/mL/mzswelpGNB+LMw61036kNCo1dpaQ9a4ev+ghlhVZfbv2ls
WVq3YgJdfHK5fON8FsI+yaCnDjk28g==
=Ay2W
-----END PGP SIGNATURE-----

--nextPart4193605.IMr3qAAT9y--