Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107206
MIME-Version: 1.0
References: <CACXBjuh_-Q6fMxQN8ddYcQQOjTU6RAZPNp9uMfg01LjvZt80ug@mail.gmail.com>
 <CAF+90c_pivhDhWbFs-qwbvSEGKU41xX6F5r3idTOwh_2f6R+0Q@mail.gmail.com> <AEED4C1B-852A-462C-A52A-1D9AD1956881@gmail.com>
In-Reply-To: <AEED4C1B-852A-462C-A52A-1D9AD1956881@gmail.com>
Date: Wed, 18 Sep 2019 09:51:21 -0400
Message-ID: <CAPKYkKyEs1UNrRpDqChQG4YEYRDwp6j3dRjUZc-zcZ=0Vidoiw@mail.gmail.com>
To: Claude Pache <claude.pache@gmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, Rasmus Lerdorf <rasmus@lerdorf.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007853090592d4227a"
Subject: Re: [PHP-DEV] Evolving PHP
From: chasepeeler@gmail.com (Chase Peeler)

--0000000000007853090592d4227a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 18, 2019 at 9:43 AM Claude Pache <claude.pache@gmail.com> wrote=
:

>
>
> > Le 16 sept. 2019 =C3=A0 21:32, Nikita Popov <nikita.ppv@gmail.com> a =
=C3=A9crit :
> >
> > * Discussion threads on this mailing list have been very unpleasant
> > recently. I am unwilling to actively participate in them in this form.
> This
> > is bad for everyone, but particularly for opponents of proposals. It
> means
> > that we cannot establish the necessary discourse to explore improvement=
s
> or
> > alternatives. The recent propensity to suppress certain discussion topi=
cs
> > entirely, as well as the use of overwhelming quantity to
> disproportionately
> > push a position, contribute to the unproductive discussion environment.
> >
>
>
> The discussion would have been less unpleasant if everyone sought
> consensus, that is, tried to find a solution that is appropriate for
> everyone, instead of trying to convince others that their opinion is the
> right one.
>
> There is a qualitative difference between consensus and unanimity.
> Unanimity means that a solution is preferred by everyone =E2=80=94 which =
is
> reasonably not possible. Consensus means that a solution is acceptable to
> everyone, even when it is not the best one for everyone. This is mostly
> possible, but only if everyone tries to satisfy not only themself, but al=
so
> the others. But consensus cannot be measured by vote.
>
> For example, throwing a TypeError for uninitialised variables cannot reac=
h
> consensus, because it is not appropriate for those that rely on implicitl=
y
> initialised variables. Triggering an E_WARNING is nearer to a *possible*
> consensus.
>
> I am not optimistic that there would be a mindset change in the direction
> of seeking consensus for every participating party of the discussion.
> However, I am suggesting that if a RFC try to seek a solution that is *at
> least* acceptable to everyone, there will be less frustration and less
> irritation from the minority.
>
>
You've hit the nail on the head. I can't speak for everyone, but I know the
while both Zeev and myself did not like most* of the ideas proposed in the
RFC, we both had mentioned the idea of making them opt-in as a possible
compromise. That proposal was flat out rejected.

At the same time, we do have to be realistic and realize that sometimes a
compromise solution isn't feasible or the way to go. If one side wants to
build a 100 yard bridge to an island, and the other side doesn't want to
build the bridge at all, compromising and building a 50 yard bridge isn't a
good solution.

* I say most, because there are a few things that we were OK with - which
goes back to something else Zeev mentioned, which is not putting so many
changes into a single RFC and/or a separate vote for each proposed change.
I personally favor limiting the number of changes in an RFC because I think
it's hard to focus the discussion, even if the votes are separated out.



> =E2=80=94Claude



--=20
Chase Peeler
chasepeeler@gmail.com

--0000000000007853090592d4227a--