Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104059
MIME-Version: 1.0
References: <CAF+90c-auGYVhCzt-1GpdU1-uZ+xiY7A_FwWSRKftuKBwtszYg@mail.gmail.com>
 <04a401d4bb7f$eb879900$c296cb00$@gmail.com>
In-Reply-To: <04a401d4bb7f$eb879900$c296cb00$@gmail.com>
Date: Sun, 3 Feb 2019 11:07:46 +0100
Message-ID: <CAF+90c_PrC7M9=R83O3W2Q3NJRCNAcuzX2yemuaB6ub6hUACzw@mail.gmail.com>
To: Zeev Suraski <vsuraski@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003d2fe70580fa8d36"
Subject: Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000003d2fe70580fa8d36
Content-Type: text/plain; charset="UTF-8"

On Sun, Feb 3, 2019 at 6:18 AM Zeev Suraski <vsuraski@gmail.com> wrote:

>
>
> > -----Original Message-----
> > From: Nikita Popov <nikita.ppv@gmail.com>
> > Sent: Saturday, February 2, 2019 6:24 PM
> > To: PHP internals <internals@lists.php.net>
> > Subject: [PHP-DEV] Alternative voting reform: Streamlining the RFC
> process
> >
> > Hi internals,
> >
> > After discussing the topic with a number of current and former
> contributors, I
> > feel that the workflow & voting RFC currently under discussion is moving
> us in
> > the wrong direction. I will not comment on the rather questionable
> proposed
> > changes to voting eligibility, as these are already extensively
> discussed in the
> > RFC thread.
>
> Personally, I find any proposal that does not deal with clearly defining
> voting eligibility not only questionable, but a non-starter, that has no
> parallels in any other major Open Source projects.
>

Why? While I think the question of voting eligibility is worth discussing
(though I also don't consider the problem pressing in any way and think
that our current pool of voters works quite well, even if it may not be
what people had in mind back then), it is, just like the question of voting
margins, a rather independent issue from the remainder of the process. I
think that these discussions and RFC can and should be split up into the
question of voting margins, the question of voting eligibility and the
question of the RFC procedure itself. While these things are of course
related, they can also be decided independently.

The problem with bundling together these changes is, if you will excuse the
political parallel, akin to bundling changes to copyright enforcement
together with a free trade agreement. Those two things have nothing to do
with each other (though of course interested parties will argue that they
are inseparable), but combining them into a single agreement makes it
feasible to pass changes that would not otherwise be considered acceptable.
At the same time, it also puts the overall agreement at the danger of
failing, due to parts that are not related to its core purpose.

I understand that there is also benefit in deciding related questions in
conjunction, in that a decision in one area would only be acceptable
conditional on a decision in another area. However, to get back to the
specific topic here, this does not appear to be applicable. For example,
your changes to the RFC workflow could be implemented independently of the
voting eligibility changes and vice versa. The only possible dependency I
see is that all proposals benefit from having the 2/3 voting margin as a
baseline (which is consistent with that RFC proceeding first, of course).


> 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

--0000000000003d2fe70580fa8d36--