Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107439
Message-ID: <B82725B4-6544-4CEE-AE11-297F08EBC4C9@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_B2761FFF-ABBC-4DDC-8D6E-31F2C50021C9"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 8 Oct 2019 17:13:53 -0400
In-Reply-To: <CANS-=pedhmAnmBSsshD8FYD2WqA-0mtWxXmXK5oqzaN8-o07Sw@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
To: Lynn <kjarli@gmail.com>
References: <5d976928.1c69fb81.db3a8.78daSMTPIN_ADDED_MISSING@mx.google.com>
 <CAF+90c9uXdqJsTizLCca-AswenZDv9-6yw=ranATp3XoutHyxw@mail.gmail.com>
 <DM5PR06MB285747B847DE2D7320758C05DE9A0@DM5PR06MB2857.namprd06.prod.outlook.com>
 <e69fb3de-df5f-f77e-ad4e-61ea30185c5c@lsces.uk>
 <CAG9XoMR9DhKDwS1moH_9pjDNyZQ70ER5_stNs_GxQFucZ+ar7A@mail.gmail.com>
 <413d377a-4ce1-a521-0cb4-5bb37e84c257@gmail.com>
 <6DFA91F7-0005-453E-A314-A5DFE1A4D3D3@newclarity.net>
 <CANS-=pedhmAnmBSsshD8FYD2WqA-0mtWxXmXK5oqzaN8-o07Sw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_B2761FFF-ABBC-4DDC-8D6E-31F2C50021C9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> On Oct 8, 2019, at 4:29 PM, Lynn <kjarli@gmail.com> wrote:
> My middle ground is a vote, regardless of outcome.

If a vote is the middle ground then why the need to participate in any =
discussion?

Also, how is a vote a middle ground? A vote ensures that one sides wins =
and the other side looses.  IOW, a zero-sum game.

Why does it not make better sense to actively look for ways to optimize =
outcomes so that the most people can win?  For example...

> This RFC is pretty simple, a deprecation + removal in a later patch, =
there's not much to compromise on the implementation.

A compromise might be "NO agreement to remove in a later patch." =20

Why does it not make sense to offer that up as a consolation to the one =
asking for deprecation?  If they accepted and changed the RFC, then more =
people could get a "win." =20

> If people think a deprecation should not be done or if it's not worth =
it, a vote is the way to show that opinion.
> If there are enough reasons to not deprecate them, the voting process =
will show this and the RFC will be rejected.

I have noticed on this list much discussion of the "minority vs. the =
majority."  But that is a red-herring. There are a small number of =
people who have a vote (~200?) whereas there are over 5 million PHP =
developers and even more PHP stakeholders who have no vote.

In other words, when internals@ votes unanimously on an RFC they still =
only represent ~0.004% of PHP stakeholders.  Basically an aristocracy.

So while a vote is a way to share an opinion, it is not representative =
of the opinions of those it may affect.  It is a shame that the PHP =
voting process has no objective way to incorporate userland concerns =
except when some act as their proxy. Which is not the same as userland =
having explicit representatives with a vote.

> PS. We need a CoC.

100% agree.

-Mike

P.S. I also think PHP needs an agreed statement of principles (Mission, =
Vision and Values.) With said statement RFCs could be evaluated to =
determine if they align with PHP's previously-agreed principles. Such a =
statement could be revised from time to time, but having one would =
resolve a lot of contentious debates before they happen.



--Apple-Mail=_B2761FFF-ABBC-4DDC-8D6E-31F2C50021C9--