Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107221
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:Content-Type;
	b=iWyxGYvgjA1EVTj2gRGAkFZzhAdJy2V5PiAv7M4JqUA21s+tTHifAtfgYBs4Tz
	Abs/V8KambGGf7WOK6hoRM/vLGVVC4UFoHkMdxuGNsdasW8obGIXD+9lecC+fy7a
	oDpkttAm7m8NaW7DxcVWJhSE1Fh8VKf8cdW32PQ+S9+is=;
MIME-Version: 1.0
References: <CA+kxMuTzACohxJcjs43f8xsJPGSMKtDygxje0r2QPmrhFiiRiQ@mail.gmail.com>
In-Reply-To: <CA+kxMuTzACohxJcjs43f8xsJPGSMKtDygxje0r2QPmrhFiiRiQ@mail.gmail.com>
Date: Thu, 19 Sep 2019 01:11:10 +0300
Message-ID: <CAJHtznxjAhtZs1JVFMpf9SUHXzopVgryhBhXPN+i=5=4_s74Ng@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000041820592db1e64"
Subject: Re: [PHP-DEV] Improving productivity of internals mailing list
From: zeev@php.net (Zeev Suraski)

--0000000000000041820592db1e64
Content-Type: text/plain; charset="UTF-8"

On Wed, Sep 18, 2019 at 8:33 PM Dan Ackroyd <Danack@basereality.com> wrote:

> # Problem 3 - Newcomers to the mailing list aren't following our
> etiquette.

# Problem 4 -  Senior project members aren't following our email etiquette.


This too isn't directed so much at Dan, but rather the list at large.

Some facts about the Mailing List Rules:

Fact #1:  The list rules were never a binding document.  It wasn't voted on
or otherwise agreed upon as binding at any point at any point.  In fact, I
can't even find any reference that it was even ever discussed (my email
archive dates back to 1999).  It was written by Lukas Kahwe Smith, and with
the exception of some whitespace and typo fixes - it's literally in an
"initial commit .. feedback appreciated" stage (
https://github.com/php/php-src/blame/master/docs/mailinglist-rules.md).
Fact #2:  It contains three chapters.  The first chapter - which includes
the goals of the document - i.e., what the other rules are aimed to
ultimately facilitate - is concluded with "Increase the general level of
good will on planet Earth". <opinion>This rule is clearly violated time and
again by several recent folks and proposals.</opinion>
Fact #3: Chapter 2 contains the rules, i.e., the supposedly binding rules
(see Fact #1). I think they're all healthy and non controversial, and we
should all strive to abide by them. <opinion>That said, interestingly, some
of the folks who most clearly violate the first item on this chapter appear
to eagerly want to enforce this document as binding.</opinion>
Fact #4: Chapter 3 contains "general hints", which are clearly non-binding
even if the document itself was (see Fact #1). Specifically, the first two
items in the 3rd chapter are purposely phrased as suggestions on what to do
as opposed to Thou Shalt or Thou Shalt Not, even if one ignores the
'general hints' label that is applied to this entire section. These items
appear to be repurposed by some here as a way to silence opposition to
extremely controversial proposals. A "you should try to do X" request in a
"general hints" section in a document that was apparently never agreed upon
as binding will not do that, nor will anything else.
Bonus fact:  Decision was only achievable through near-consensus back in
the day these rules were written; Substantial opposition wasn't facing the
risk of being ignored and overrun as it does today..

There's another fact about what RFCs can or cannot do, but I think I've
spent enough digital ink on that already.

The recent discussions we've had on this list were not pleasant for anyone.
To say I took no pleasure at the discussions of the last few months would
be a top contender for the understatement of the century. However, from my
POV - I had no choice in the matter - and had to react to discussions that
were imposed on me. The alternative - which I view as betraying countless
users - isn't a real alternative from my point of view. I know for a fact
that many others had similar thoughts (yes, beyond just Chase and Stas) -
but were wary about voicing their opinions when they saw the 'summary
trials' I faced in certain forums, or just didn't have the energy to fight
what appeared to be a sisyphic task against an internals@ majority that
doesn't seem to care.

There are very few folks on internals@ that are actively working to protect
PHP's excellent BC track record, as well as keeping it from severing its
roots.  It does mean that they are disproportionately represented in such
discussions.  While I would absolutely love there to be others that will
join this effort that is as of late repeatedly imposed on us - we will
continue doing what we have to.

Ultimately, the only way to avoid having these tiresome, waste of time
controversial discussions, is to stop bringing up controversial zero sum
game proposals.  If you accidentally bring one up - backtrack, and figure
out a win/win solution or simply abandon it.  If you insist on following
through with it - while spending plenty of Good Will credit and forcing
people to defend their positions - expect to have to endure a pretty tough
debate.  No mailing list rules or RFCs will change that.

Zeev

P.S.:  Intimidating folks by "noting their response time" - when their
response clearly doesn't violate anything about the rules - isn't only
gross, it's a downright regression to 1984.  The antithesis for the stated
goals of the document, and knowing Lukas - probably the very exact opposite
to what he had in mind.  Nobody should do that.

--0000000000000041820592db1e64--