Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107193
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=turbo-smtp; d=php.net;
	h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type;
	b=YjLKsdMZJCWQPDSmR/Kw5zNHA1WvJ4SnRW/vBrWx0qRCJ74X9iFn9tjOxn9MiS
	f9Dd7zQl6nu2CyWD64Vimq8GrGhPGk6yTRkuS/aF8jU9Ksw/b1PvPU7lRHi1v9HO
	Oqi9L7hpS2YhQKT40qG7goNIzEto1RHrZq97sfrAtmYxA=;
MIME-Version: 1.0
References: <CAOwTYAu5vCGMw4Dp0v90fGD9OGm6X0dc42iJV35bk1Df_yr_2w@mail.gmail.com> <CAJvSBVOPyxUkLsUc2a8z2HSOdGtYk-Jci=DsdeMfa2sQqH1SKw@mail.gmail.com> <CAJHtznwizncbEMLOYyLt6MN1XyNzEZjYVMwe7uFuhsEO5_Y=_g@mail.gmail.com> <CAJvSBVMSTYD-5GhHAxGzQGbus3HSquuRBU5+JVk=WUdVV5iGJg@mail.gmail.com> <CAOwTYAvcKMRK1NmZ3rDmw3g4ExdXM8E3-jcgRYrB7bTJrx9UnA@mail.gmail.com> <CAEZPtU7fwUhB7uZJTfTig7QZJGdC+3OAKzgMyhr87kjMEzuQbg@mail.gmail.com> <CAEZPtU6W-K_=kcfqXNB0Fbh2KYkz65fGTyahdq8pCLvcphN8sQ@mail.gmail.com> <CAOwTYAt_BLu-N-fcsvUTTXcAc3dBX4gkKjgcuUmknvsy5jEH-w@mail.gmail.com> <CAEZPtU793uiVa_=1dZth6dXUs03V=otzBCrhbRCABuVS_mQFOA@mail.gmail.com> <CAOwTYAvwSp-50PVCjUH7T1E2zU3wnUE3HtpK8ZxEfH-FjMrJbA@mail.gmail.com> <6067334c-b327-9ad7-aff3-11f3208813ee@gmail.com> <4f3978bc-a362-4424-a8aa-7258794e5c8b@www.fastmail.com>
In-Reply-To: <4f3978bc-a362-4424-a8aa-7258794e5c8b@www.fastmail.com>
Date: Tue, 17 Sep 2019 18:41:18 +0300
Message-ID: <CAJHtznzACkSNRTmvXLotSHzrAyBGM8dTCiNw=RHcOk0LCy7tYg@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000eb042a0592c18de4"
Subject: Re: [PHP-DEV] Defining the PHP Group
From: zeev@php.net (Zeev Suraski)

--000000000000eb042a0592c18de4
Content-Type: text/plain; charset="UTF-8"

On Tue, Sep 17, 2019 at 3:32 PM Larry Garfield <larry@garfieldtech.com>
wrote:

> Simple question for those that keep arguing that the RFC process is only
> applicable to a certain subset of issues:
>
> OK, so what's the alternative?
>
> If we wanted to make a structural or governance change to PHP, what is the
> process?
> If we really did feel there was a reason to make a fundamental change to
> the language (whatever that means), what is the process?
> If we wanted to change the RFC process, what is the process?
> If we don't have those, and want to set them up, what is the process for
> defining the process?


For the first and last one (which are kind of the same) - the answer is
simply the (informal) process we had before the RFC process was enacted.
That effectively meant consensus based decision making.
Since we have a lot more people today, we can and probably should reuse the
voting mechanism, and a pass would have to look along the lines of this:
https://web.archive.org/web/20120527111218/https://wiki.php.net/rfc/voting/vote

or
https://wiki.php.net/rfc/abolish-short-votes

If you look at all the 'Process and Policy' RFCs we've voted on, other than
a couple that are miscategorized technical RFCs - they virtually all
cleared a 15 to 1 bar, most of them well above that.  When changing the
rules - or extending the scope of the RFC process to handle things it never
has before, this is what it takes.  We haven't implemented any rules that
bind everyone without that level of widespread agreement to this date.

Consensus based decisions would work for the 3rd one as well and would
probably be the simplest to enforce.  It may be that for RFCs that place
new limits on it (like the recent Abolish votes) a 2/3 bar would suffice -
although I think it's healthy for everyone that the ratio that was reached
was more along the lines of 20 to 1 than 2 to 1, in terms of everyone
accepting the validity of the policy change (including the fingerful who
voted against).  But since determining whether a policy RFC falls in that
category or not can in itself be challenging, having a single, clear high
bar for introducing both changes to the Voting RFC, as well new policy
rules, would probably be the simplest and probably healthiest outcome.

Regarding the 2nd (fundamental / high impact changes) - the solution here
too would be consensus based decision making.  That's the bar we cleared in
previous major changes - the deprecation of register_globals, magic_quotes
and safe_mode.  Now, I think Nikita does have a point that defining what
constitutes a 'high impact' break vs. one that isn't very easy - especially
in a formal manner.  So it may make sense to have a single bar for all
compatibility breaking changes, instead of a separate one for high impact
ones and low impact ones.  The solution might be to simply gauge the level
of caring through the number of voters who took the time to vote.  For
instance, a change proposal that garnered 10 votes, 7 to 3, is probably not
a high-impact one and it may be reasonable to accept it even if it only
cleared a 2 to 1 ratio.  A change proposal that garners 50 votes and is 35
in favor and 15 against (exactly the same ratio, but with a lot more
voters) - is most probably a high impact one, and should clear a much
higher consensus-level bar.  In the meantime, formality aside, it's easy
enough to 'know it when you see it'.  I don't think anybody contends that
changing our undefined variable behavior or deprecating short tags are
high-impact breaks - in terms of the lines of code in the combined
universal PHP code base that would have to be changed as a result.

Other than the higher bar - I think such proposals should be required (or
at the very least encouraged) to do a better impact analysis regardless.
They should be tested on a set of apps (one that will attempt to represent
the PHP codebase at large, not just the cutting-edge framework
development), and the results should be available as a part of the RFC.
Even if we can't formally compute from that data whether it constitutes
high-impact or not, having that data as a part of the RFC will likely help
voters determine their opinion on it - first at the level of whether they
care or not, and secondly - whether they're in favor or not.  This will, in
turn, effect voter turnout - and help determine whether this is indeed a
major change or not.

In addition, I don't think we should be grouping any deprecations together
into a single vote - unless that's absolutely required from a technical
standpoint (i.e. doing one without the other would lead to an
inconsistency).  With the recent engine errors reclassification RFC,
initially - the deprecation of default values for uninitialized variables
wasn't even viewed as a very big deal and was grouped with the rest.  It's
true that this quickly became apparent and Nikita separated it after a
couple of days - but I think that should be a requirement, and not up to
the RFC author.  I also agree with Christian - the fact that this
deprecation was by far the biggest one - basically distracted everyone
(myself included) from discussing the smaller ones.  This means that while
there are probably some issues with some of the other, smaller changes -
the fact they're lumped together with others which are harmless, and the
fact there was practically no discussion over any of them - means it's all
too easy to vote in favor of changing the entire group.  Combined with no
impact analysis being available for each proposal - it's very likely that
there's 'herd mentality' happening there.  Putting each in a separate vote
would have likely not thoroughly solved this, but it would have probably
been a good first step, allowing more granular choice.  I think that this
particular change (requiring separate votes for each change) can be done
relatively easily within our existing framework - similar to the Abolish
RFCs, if there's widespread agreement.  In the context of Ben's email from
a few weeks ago, I'll defer to someone else to propose it if they think it
makes sense.

Zeev

--000000000000eb042a0592c18de4--