Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107260
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=bHZ+nfZEjNBGhNEJ8DWpeW8vqSLh2bWAAZxCaQezLaDNzrrF1K7KO8/vk9nxXo
	J9lamjJc8RUSBeCvqKRVzuZV2qgFPh0gFDszLE3FugLcoIeYQyFP8HDCvKwLsVnp
	jhBcKLRQq/l6XcrDOzq4OA6xrA2tuyKSeLU3Rr+JQSz0U=;
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>
In-Reply-To: <893cc688-c8a2-1da3-e72c-de952f3f774d@heigl.org>
Date: Fri, 20 Sep 2019 12:52:54 +0300
Message-ID: <CAJHtznzyS=Ut88A25qtgb=2A6_Vm+w3uPHgvZ3f2yvfjtTJopA@mail.gmail.com>
To: Andreas Heigl <andreas@heigl.org>
Cc: Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000676bbe0592f909d5"
Subject: Re: [PHP-DEV] [RFC] Prevent disruptions of conversations
From: zeev@php.net (Zeev Suraski)

--000000000000676bbe0592f909d5
Content-Type: text/plain; charset="UTF-8"

Andreas, all,

Speaking of 'disruptive behavior' that the antithesis of promoting 'good
will' - this pseudo RFC is a textbook example.
But some of the responses on the thread are actually more interesting and
nicely written and do warrant a response.

On Fri, Sep 20, 2019 at 10:14 AM Andreas Heigl <andreas@heigl.org> wrote:

> Hey Stas, Hey All.
>
> "without too much problem"... I start to ask myself whether I read the
> same mailinglist as you...
>
> "rare disruptive individuals"... Again I ask myself whether I read the
> same mailinglist...
>

Different people have different expectations from what discussions should
look like.  Their personality, culture and other elements may feed into
that.
For some here, the most important thing about internals should be
individuals not writing too many emails on the same topic.  For others -
it's for people not to use foul, disrespectful or condescending language.

Thankfully (or not, depending on your point of view) - internals@ wasn't
born in 2019.  It's with us for over twenty years - since the project was
born.  Making decisions through discussions and debate is the DNA of the
list, the DNA of the project.  Discussions about contentious topics can get
intense. They can end up with certain folks being over-represented in
certain threads.  This never has been and will not be considered abuse, it
comes with the territory.  No RFC is going to change that - the list and
our most fundamental way of working predates the RFC process by almost 15
years and cannot be altered by it.

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.

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,
because the way they are conducted isn't pleasant for some (or perhaps even
many) of the readers and participants.  We're talking about codifying a new
DNA - that nothing is off limits for the Voting RFC, even turning PHP into
a strictly typed language breaking every last piece of PHP code out there -
if there's 2/3 support for it - a bar that was set for new features.  That
won't happen.
More specifically, as Brent pointed out, we all know who this is aimed at.
It's aimed at me, Stas and Chase - who fiercely opposed the recent new
break-fest trend, and happen to remember the key tenets of the PHP project
- even if they're not fully encapsulated in the hastily written Voting
RFC.  And all of this just happens to be promoted by folks who supported
that very same break-fest, and are repurpusing the RFC process to have
unlimited power about both conduct and radical, super controversial
breaking changes.  Despite claims to the contrary, this is no coincidence.

The unpleasantness of these discussions - which I'll be the first to admit
(I have, *literally*, lost sleep over some of them) - is no indication of
their validity.  As an example, as unpleasant as the discussion surrounding
the 2nd fixed short_tags RFC was - and it was, for *everyone* involved -
the difference between the results of the 1st and 2nd round of this RFC
demonstrate the value of an open discussion - even if it's unpleasant.
Yes, the discussion around round #1 was nice and pleasant, in fact it was
virtually non-existent - and it was a textbook example of a *horrible*
discussion
process.  Our first goal on internals@ isn't to have fun (although that's
of course not a bad thing, and every once in a while that may happen too) -
it's to come up with the best decisions for PHP.  While discussions have to
be respectful - it does not mean they'll necessarily be pleasant.  Whether
one gets involved in a discussion is their choice - and that's more true
for RFC authors than virtually everyone else.

As I recently wrote - if someone is going to bring up a controversial
proposal (especially ones breaking new grounds in terms of impact) - they
should be absolutely ready to deal with potentially fierce opposition.  If
they do it inadvertantly - they have the option of reevaluating whether
it's worth their trouble.  They do not have the option to silence others'
on-topic feedback, period.

"without dramatic speech code"... Yes. That was exactly the problem. No
> process that was agreed on *before* shit hits the fan.
>

Had we wrote a speech code back in the 90's, placing message count limits
would definitely not have been a part of it.  Even the mailing list rules
that Lukas wrote 12 years ago don't place arbitrary limits on messages, but
ask the participant to think about whether he truly needs to frequently
respond.  In some of these recent threads, given the gravity of the
situation and the scarcity of folks that were willing to actually campaign
against the proposals (despite there being many who agreed with them) - it
was absolutely warranted.


> To me it looks like you are trying to make this RFC look like it tries
> to force a ban on people that want to contribute. While this is not the
> idea of the RFC I ask myself why you are so strongly against trying to
> find a way to get a less disruptive email-list.
>

Simple - in a parallel universe where this was binding - we would have
likely deprecated short tags and undefined variable access.  We would,
have, perhaps, decided to turn PHP into a strictly typed language by 2028 -
because it's supposedly a long enough timescale for everyone to adjust to a
radically different language, or be forced to stick with LTS.
Because it is politically motivated and would have been used to oppress an
internals@ minority - a minority that already has very few speakers willing
to take the heat of the discussions repeatedly imposed on us (but at the
same time represents a sizable minority).

A toxic and disruptive email-list that drives the creation of PHP not
> only drives people away that would like to contribute to the language
> itself but also drives people away that might want to use PHP for their
> projects but are not sure about whether the language is such a good
> choice if that is the tone of development. People will leave PHP because
> they are not sure whether PHP has a future when the people creating the
> language can't even decide on how to talk to one another...


The way to avoid contentious discussions, especially repeats of the ones
we've had recently, is to come up with a solution that will prevent these
contentious topics from being an issue to begin with.  Not coming up with
ways to silence dissent so that we can have a nice kumbaya discussion while
the majority[*] overruns the minority[*] (* - on internals@, at least).

Strict mode/Editions/similar options would have provided proponents of a
stricter/'cleaner' PHP a good way forward - not just for these issues but
for a whole class of others, while not imposing a gigantic headache and
depressing changes on lenient/BC-oriented folks.  It would have taken away
the whole source of contention - for an entire new family of topics that
appears to have popped up in recent months.  It would have made the whole
RFC scope discussion irrelevant - as it has been for the better part of a
decade.  It would have promoted good will for *everyone*, not just the
majority camp that manages to overrun the other or minority camp that
manages to stop the other in its tracks.  It would have been a win/win.

This is the kind of solution we should working on.  And yet, any attempts
to start discussion on those was met with deafening silence or worse.
There seems to be a lot more appetite to devise new ways to silence
dissenting voices.  Are folks in favor of such new rules truly after a less
toxic internals, or is it more about eliminating the pesky opposition that
stands in their way to implement the one-sided vision they believe in?
Because if it's a less toxic internals we're after, agreeing on frameworks
mostly everyone can live with would go *a lot* farther than synthetically
placing arbitrary limits on debate.

It's never too late.

Zeev

--000000000000676bbe0592f909d5--