Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107266
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>
In-Reply-To: <CAJHtznzyS=Ut88A25qtgb=2A6_Vm+w3uPHgvZ3f2yvfjtTJopA@mail.gmail.com>
Date: Fri, 20 Sep 2019 13:24:25 +0200
Message-ID: <CAEPJdunTm4gMLUk5-+4-PJQcdvNdsVvByk5dMNO-mNptGc7WUQ@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: Andreas Heigl <andreas@heigl.org>, Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b240870592fa509c"
Subject: Re: [PHP-DEV] [RFC] Prevent disruptions of conversations
From: kontakt@beberlei.de (Benjamin Eberlei)

--000000000000b240870592fa509c
Content-Type: text/plain; charset="UTF-8"

On Fri, Sep 20, 2019 at 11:53 AM Zeev Suraski <zeev@php.net> wrote:

> 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.
>

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.


> 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.
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.

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.


> 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.
>

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.

I would really like to see that you propose an RFC with the technical
details of how a strict mode should look like and work. Then we can finally
discuss it based on how it would work and not how it could look like.
But by never actually proposing a technical solution I feel that the
discussion just drags on unproductively.


> 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
>

--000000000000b240870592fa509c--