Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107157
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:Content-Type;
	b=tBT2ik4f2S/e8l/ToVMGId3eGkvz3HER7CEUimt/7zDoHJifzPTp1nqqvzYGjB
	E0dU41gHtBgWuoHvXqSxSzxefdaGh3ZLOu3naH8FhIILP0Cedrzm5/v98JvHHLMz
	6yJRO8BsQEIavXJuw3UREVqYeW8nGFnHCUPHFcE2a9IA8=;
MIME-Version: 1.0
References: <CAOwTYAu5vCGMw4Dp0v90fGD9OGm6X0dc42iJV35bk1Df_yr_2w@mail.gmail.com> <CAJW__o2zGs_s0NRznZiG5Wb5NSeRMDzitS5457hGg_xMJ3B0dQ@mail.gmail.com> <CAOwTYAuqas930BODamWEuMaH7T1N6H8y2fP1B+cjMkkVfi0rQw@mail.gmail.com>
In-Reply-To: <CAOwTYAuqas930BODamWEuMaH7T1N6H8y2fP1B+cjMkkVfi0rQw@mail.gmail.com>
Date: Mon, 16 Sep 2019 12:05:05 +0300
Message-ID: <CAJHtznwccyuHyujAU+j+E15doFbvFPaGY+Vf1hbB5btZd=O7Ug@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000d36cf0592a7e7a8"
Subject: Re: [PHP-DEV] Defining the PHP Group
From: zeev@php.net (Zeev Suraski)

--0000000000000d36cf0592a7e7a8
Content-Type: text/plain; charset="UTF-8"

This note isn't really for Joe, who will likely would not pay too much if
any attention to whatever I or whomever else who disagrees with his
position on the universal applicability of the Voting RFC in its current
form has to say.
This is for the many other folks following this and other threads.

On Mon, Sep 16, 2019 at 10:33 AM Joe Watkins <krakjoe@gmail.com> wrote:

> I'd like it if we could stop saying the RFC process can't be used for one
> thing or another, it's patently false.
>

Saying that something is patently false doesn't make it so.  Repeating it
in multiple ways doesn't make it so either.  And indeed, the RFC process
can be used for a wide range of use cases - and at the same time it isn't
and never was a way to govern every aspect of the project.  The notion of
'one size fits all' is frankly ridiculous.
This process was introduced in a certain context, and while it's true that
it evolved to also cover some other elements it never ventured into
radically different areas as it appears to be doing now.  Currently, it's
mutating to cover an entirely new space - the space of radical breaks -
it's time to put it back in perspective, and agree on how we're going to
handle these things going forward.

To say it's not suitable for these things is a total nonsense, we already
>
use it for these things.
>

Determining that a process that was devised for a certain purpose is
suitable for every other purpose under the sun is, in my humble opinion,
not very sensible.  Adding a feature and taking it away - let alone so
after 20 years - have radically different effects.  The former doesn't
immediately do anything (at least not negatively).  The latter - depending
on the details - could have far reaching overnight effects.  It's not just
that the RFC process wasn't meant to cover that.  It's that treating both
cases as if they're the same thing doesn't make any sense at all.

Yes, using the process itself to amend it was a bit questionable - but
since it did not extend the scope and jurisdiction, it wasn't a big deal.
It also passed nearly unanimously - so whatever bar we would have had, it
would have likely cleared it.  It does not mean that the same process with
the same bar can be used to extend its jurisdiction to additional areas.

Specifically, areas where it cannot extend itself into are the areas such
as radical changes to the project governance and radical shifts in the
language.

It's not that the process in itself is not suitable.  Much of it can be
reused for these purposes.  However, if we are going to make radical
changes - be them in the language or in how we work - there needs to be
overwhelming support for it - similarly to the level of support we had for
the RFC process itself and its amendments.  Also similarly to when we
deprecated major features like like register_globals, safe_mode and
magic_quotes - there was also near unanimous support for it, which was more
along the lines of 10 to 1 than 2 to 1.  And arguably - all three were much
'smaller deals' than the radical deprecation that is currently on the table
- register_globals and magic_quotes had simple one liner workarounds, and
safe_mode had its scope limited to shared hosters only - and was (almost)
unanimously agreed upon as a feature that was simply not working as
advertised.

If we want to extend the Voting RFC to cover things such as radical changes
to the language, or introduce radical changes to the project governance
(e.g. CoC) - it would have to clear a similar bar.  You need overwhelming
support for changing the rules that bind everyone.  Yes, I realize people
think that it is me who's changing the rules - but it isn't.  It's no
coincidence that the applicability of the RFC process is coming into
question now - it's being used - for the first time in a few short months -
to do something it was very clearly not designed to do.  It simply never
happened before.

It's not that we can't apply large parts of the RFC process to these areas
as well.  We can and should.  But we'd have to modify some elements and add
some others.
For areas like radical changes in project governance (i.e., not amending
the Voting RFC within the same scope, but say, extending it;  Or
introducing a CoC) - it would have to clear a much higher bar.  Whether
it's 5 to 1 or 10 to 1, it can clearly not be 2 to 1.
Similarly, for deprecations - we'd need a way to measure the expected
impact, and determine the bar in correlation to that expected impact.
Deprecations with minor impact could perhaps still use the 2/3 bar.
Radical shifts that are going to affect hundreds of thousands of people or
require auditing of billions of lines of code - would have to clear a much
higher bar - and would have to include a much stronger analysis than 5
sentence in a composite RFC.

The 2/3 bar encourages contention, and worse - as we can see in recent
months - enables tyranny of a majority - forcing change on the minority.
Moreover, the specific recent example of what happened with short_tags
illustrates just how unsuitable the RFC process in its current form is to
handle radical deprecations.  The 2/3 bar was meant a reasonable bar to
ensure that the support isn't some temporary "50%+1" - that would then
commit us to perpetually supporting a feature that we weren't too confident
about as a team.

We are in control of a gigantic platform that is used by millions of
people.  The RFC process gave folks access to influence the future
direction of PHP in a way that has few if any parallels in Open Source
programming languages.  Perhaps this confused people to think that we
(internals) can do whatever we want with it using the same relatively
achievable bar.  That is not the case.

On a personal note, I'm well aware that many are perceiving this as if I'm
trying to take control of the project, or driving people away, or generally
being aggressive.

Reality is slightly different.  The folks who are triggering these
discussions are the ones who are trying to both bring change to PHP, and at
the same time refuse to compromise or even explore win/win solutions.
Sure, others have the option to just 'suck it up' and see the project we've
worked on and/or have been using for years take a radical turn into being
something different and push us away.  In recent months, I've repeatedly
tried to come up with, bring up or accept constructive solutions - that
would not disenfranchise one camp at the expense of the other, but rather
give both camps what they want.  But it appears that the current majority
insists that they don't only get what they want - but that they do it while
taking away what the minority wants.  This cannot stand.  As I said
repeatedly, we need to snap out of the zero sum game mentality and come up
with solutions that work for mostly everyone - certainly not just 2/3 of
internals (and probably a lot less of the PHP world at large).

I'm not saying I can veto decisions, and going down the line of figuring
out whether the PHP Group can do so is the wrong direction that's entirely
non productive.  I'm not trying to "take back control" of the project.
There's absolutely nothing personal at play here for me, I wish I didn't
have to be involved in this.

What I am saying that the RFC process in its current form is inapplicable
to the discussions we're currently throwing at it.  I'm also suggesting
that we need to move back to be a bit more consensus driven with decisions
that affect everyone.  Concensus on such areas doesn't have to and will not
mean paralysis.  PHP has evolved a lot in recent years, and will continue
to do so - the 2/3 bar along with the composition of internals@ ensures
that.  It's just that if we want to evolve it in a direction that would
negatively affect a very large group of people (break their apps) - we need
to do better than that.  There either needs to be an exceptionally good
case for it which would result in overwhelming support - or we need to find
a way to introduce it without breaking people's code.  That can absolutely
be done - even in a variety of ways (Editions, strict mode, P++, other
ideas) -  it's not even very complicated.  All it takes is some good will.

Zeev

--0000000000000d36cf0592a7e7a8--