Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107268
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=RyrKUbblutSi3i9E8wWqBtSoa4Q+182RIDg4FkZv7ZPYyGazQmVOq17O47ezh6
	1ggdHCIC81wufYFfnieanQ5tL661sDtbnz5NiGL4dxDujw5RUU9xHjcilbjDJyLZ
	f86TcoKYtnadlO+ptQe0QHdoKmla2IdIOBrQ3yEU6UZM4=;
MIME-Version: 1.0
References: <CA+kxMuSkkhtvaBk_89j+PM_TmHDhtOiJ=RxsoV-q5wLtwE_ZHA@mail.gmail.com> <CAPKYkKyJDW4hys4-NdYy7MXsegGDx-GydrwWUOJma8e3UNRbBg@mail.gmail.com> <CA+kxMuS5A7sxS6G-14U5F1abgJypX3LLeYOD0JGfVufNzcqtnQ@mail.gmail.com> <CAPKYkKwts9Lw8OYS8P6GJ9bjfNjz4hcjsnuS44MDh0v8N7MoQg@mail.gmail.com> <CAJW__o08OTOwk3VVq8-KoYY+_q5HOXODxNyXiUFe_oaLok_mLg@mail.gmail.com> <2145814f-dbf2-9555-138b-4ed51b96522f@gmail.com> <893cc688-c8a2-1da3-e72c-de952f3f774d@heigl.org> <CAJHtznzyS=Ut88A25qtgb=2A6_Vm+w3uPHgvZ3f2yvfjtTJopA@mail.gmail.com> <CAEPJdunTm4gMLUk5-+4-PJQcdvNdsVvByk5dMNO-mNptGc7WUQ@mail.gmail.com>
In-Reply-To: <CAEPJdunTm4gMLUk5-+4-PJQcdvNdsVvByk5dMNO-mNptGc7WUQ@mail.gmail.com>
Date: Fri, 20 Sep 2019 18:03:42 +0300
Message-ID: <CAJHtznxWO2zHpPKqTQ82W3cK85v+pqDXE-aNza7adbUv4Vxpfw@mail.gmail.com>
To: Benjamin Eberlei <kontakt@beberlei.de>
Cc: Andreas Heigl <andreas@heigl.org>, Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000edb25b0592fd6080"
Subject: Re: [PHP-DEV] [RFC] Prevent disruptions of conversations
From: zeev@php.net (Zeev Suraski)

--000000000000edb25b0592fd6080
Content-Type: text/plain; charset="UTF-8"

On Fri, Sep 20, 2019 at 2:24 PM Benjamin Eberlei <kontakt@beberlei.de>
wrote:

>
>
> On Fri, Sep 20, 2019 at 11:53 AM Zeev Suraski <zeev@php.net> wrote:
> This style of conversation has regularly lead to contributors that don't
> want the intensity quit contributing silently. It is not healthy for this
> community.
>
> Just because this style of communication was the DNA for 20 years doesn't
> mean it has to be for the next 20 years.
>
> Some people can discuss a topic over and over again, maybe even get
> strength out of it, others reach their limit of discussions at much earlier
> points and turning inward and away.
>

This isn't so much a matter of a 'style of communication'.   It's a matter
of being able to address an evolving discussion and exhaust all the
different aspects of the topic at hand.  Yes, it can be, well, exhausting -
but since we deal with decisions here that influence millions of people -
this is absolutely the right thing to do.  Let's take this very email for
example.  Your reply to me, and my reply to you.  Am I supposed not to
reply back, even though you brought up several new points?  Even though you
mentioned several things which I addressed in the past, but were perhaps
not fully understood?  Is someone with a minority opinion, who receives
messages from multiple people at a given point, limited to answer just one
or two of them, instead of addressing all of their points, because
otherwise he'd be "sending many more emails than other contributors"?
Placing arbitrary limits on conversations is not the answer.  If we make
internals more welcoming to contributors at the expense of shallower
discussions - which result in catastrophic accidents for millions of end
users - this is not a Good Thing.  The right way is to build frameworks
that allow us to roll out changes in such a way that everyone can live with
them.

Abuse - the kind of which we banned less than a handful of folks for so
>> far, is something entirely different than what is being discussed here.
>> Real abuse - abusive or foul language, off-topic rants, especially from
>> people with no contribution track record - *might* constitute grounds for
>> banning someone, although that is a very extreme case that should only be
>> taken when a person clearly adds nothing to the discussion.
>>
>
> There is no rule for absue yet though, and clearly specifiying these rules
> as done in Dan's RFC would help soothe the discussions.
>

Not necessarily. Rules are up for interpretation. It's somewhat similar to
laws in the context of countries - laws are laws, but ultimately, the only
ones who can decide whether something is lawful or not are judges - and as
we all know, their decisions can often be extremely controversial.  Two
judges could interpret the exact same law under the exact same
circumstances in entirely different ways.  And that's when we deal with
judges for whom its their job - not untrained techies who may also have
their own opinion on the discussion at hand.

I imagine it would never be needed other than for simliar things than the
> bans that happened before. But they provide a framework
> that prevents these situations from draging on too long, escalating.
>

>> We both know that this isn't what's being discussed here.  What's being
>> discussed is placing arbitrary limits on and curbing on-topic discussions,
>>
>
> This is exactly *not* what is discussed here. On-topic discussions are
> totally fine.
>
> We have all read your, Stas and Chase's opinion and looking at the result
> not a zero number has taken it into account for the engine warnings RFC.
>
> It is the ferocity, amount and wording of stating the opinion that I am
> personally not OK with.
>


I'm not following.  You're saying that [1] on-topic discussions are totally
fine aren't being discussed here, go on to suggest that [2] the points from
Stas, Chase and myself probably did result in some folks changing their
opinion - and then go on to say that [3] in fact, they weren't OK in your
view because they were too ferocious, wordy and opinionated.  If [3] is
simply your opinion, then that's fine.  However, in a parallel universe
where these proposed rules were binding - it may mean that some of us or
all of us would get suspended for them.  In turn, it may mean that the
results of the corresponding polls would have changed.  In other words,
they absolutely would affect on-topic discussions, placing arbitrary limits
on them and creating a mechanism for a majority to silence the minority.

This email of yours https://news-web.php.net/php.internals/106963 really
> overstepped many lines in terms of aggresiveness.
>
> To me this feels like your attempt of shutting down dissent and silencing
> different opinions with ominous threats by abusing your position of power
> in the project.
> I hope you see this and why contributors feel the need to clarify rules.
>

While I agree it was a far-reaching message that I did not want to write -
I still stand behind it.  Nothing in this message threatens to ban or
suspend folks who would continue campaigning for their opinions.  It does
make it clear, though, that if your opinion is that OTHERS *must* change
the way they use PHP to fit the way and/or style that you prefer - this is
fundamentally incompatible with key tenets of the project that far predate
the RFC process - and that this process (and in particular the voting bar)
was not designed to address.  It's somewhat similar to the freedom
principle in free societies - you're generally free to do as you please -
however, that only holds true as long as you don't violate the rights of
others . Preventing someone from being allowed to hit someone else does not
constitute as limiting their rights.  Back to our world - one would have to
find an approach to promote their idea that does not force their way of
thinking and coding style on everyone else.

More than one such way is available.  Until the RFC was put to a vote, me
as well as others were cautiously optimistic that at least this part of the
proposal would be retracted.  About a week earlier - there were indications
that this whole thing may be resolved by changing default INI settings
instead of triggering a giganetic behavior change and a BC break.  But
despite the positive reception to this idea - that positive reception went
ignored for reasons unknown, and the RFC simply charged ahead.


> Nobody is against discussing a strict mode. But at the moment this
> discussion is constantly derailed, because there are no actual technical
> proposals how this looks like and if nobody is workong on it, then it will
> not be happening.
>
> With speculation on the issue then comes the contentiousness in
> discussions. We can only speculate how the castle in the air looks like.
>

First off, I'm absolutely sure that folks who proposed the recent gigantic
BC breaks know precisely what 'strict mode' would be, how easy it is to
implement, and if they wanted to go in this direction - they wouldn't need
my help.
It's directly related to the strictness proposals that are being brought up
here (short_tags deprecation, undeclared variables behavior, etc.) - and
bringing it up in that context isn't at all derailing the discussion.

Strict mode, somewhat like in Perl (https://perldoc.perl.org/strict.html)
and JavaScript (
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode)
-
would be a PHP level switch that would trigger several
compatibility-breaking changes that would make PHP stricter and 'cleaner'.
In terms of what it would look like and how it would behave - the simplest
way would be reusing declare(), and have the exact same semantics we have
for strict_types.  We could decide whether we want to roll out these
changes as a single switch (e.g., declare(strict=1)), or whether we'd want
something more granular (e.g. declare(strict=SHORT_TAGS|UNDECLARED_VARS).
And that's kind of it.  There isn't that much to it.   If & when Nikita or
someone else comes up with a mechanism to apply such declare()s at the
namespace or package level - this mechanism would benefit from it as well.

This isn't a castle in the air.  This is buying the Versailles palace for
$9.95.  It's ridiculously easy to implement.  It's easy to explain.  It's
easy to use.  The concept has been tested for several years through
strict_types.  The only downsides it has are that it doesn't force this new
behavior on everyone and doesn't break astronomical numbers of lines of
code.  But really, these aren't downsides - they are prerequisites to
making it an idea worthy of discussion.

Zeev

P.S.:  Thanks for a well thought-out email.

--000000000000edb25b0592fd6080--