Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90603
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 207.46.100.148 as permitted sender)
To: Derick Rethans <derick@php.net>
CC: PHP internals <internals@lists.php.net>
Thread-Topic: [PHP-DEV] Re: Internals and Newcomers and the Sidelines (WAS:
 Adopt Code of Conduct)
Thread-Index: AQHRTPE4uU/NmWjyCkirbyNhGk+Jh574DeYAgABkTWCAANatgIAAHPpA
Date: Wed, 13 Jan 2016 13:57:05 +0000
Message-ID: <BY2PR02MB2983F0BFC7CB364676CF177ACCB0@BY2PR02MB298.namprd02.prod.outlook.com>
References: <8B865D2A-6762-430D-9EA1-9B693DE8E8C3@zort.net>
 <56948002.1080802@gmail.com> <A51E3740-45AD-4522-AFB6-74698066DB95@zort.net>
 <BY2PR02MB2988A3093E76D1E675BFD74ACCA0@BY2PR02MB298.namprd02.prod.outlook.com>
 <alpine.DEB.2.20.1601131049220.3314@whisky.home.derickrethans.nl>
In-Reply-To: <alpine.DEB.2.20.1601131049220.3314@whisky.home.derickrethans.nl>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: zend.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2016 13:57:05.5775
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 32210298-c08b-4829-8097-6b12c025a892
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR02MB297
Subject: RE: [PHP-DEV] Re: Internals and Newcomers and the Sidelines (WAS:
 Adopt Code of Conduct)
From: zeev@zend.com (Zeev Suraski)



> -----Original Message-----
> From: Derick Rethans [mailto:derick@php.net]
> Sent: Wednesday, January 13, 2016 12:59 PM
> To: Zeev Suraski <zeev@zend.com>
> Cc: John Bafford <jbafford@zort.net>; PHP internals
> <internals@lists.php.net>
> Subject: RE: [PHP-DEV] Re: Internals and Newcomers and the Sidelines
> (WAS: Adopt Code of Conduct)
>=20
> On Tue, 12 Jan 2016, Zeev Suraski wrote:
>=20
> > I think that no matter what we do, CoC, guidelines or teams we have in
> > place - as long as there'll be divisive RFCs, there are going to be
> > heated, toxic discussions.
>=20
> I think the main issue is the whole concept of "divisive RFCs" as a term.=
 An
> RFC is a request for *comments*. Instead of people saying
> (paraphrased) "that is crap, unwanted, needless", the whole point of an R=
FC
> is to improve the proposals - before a vote is arranged.

While RFC does stand for 'Request For Comments', in practice it's much more=
 than that.  It's the declaration of intent to introduce a change subject t=
o a vote on a relatively short timeline. =20

In some cases, the proposed ideas are awesome and enjoy consensus.  In some=
 cases, they're downright bad - or at least perceived to be bad by an overw=
helming majority of the voters, or are even withdrawn before going into a v=
ote.  Then, there are those ideas that create two polar groups, both sizeab=
le - with one thinking the idea is awesome, and the other thinking it's awf=
ul.  Those are the ones that are causing the heated debates on internals, a=
nd those are the ones we need to find a way to avoid.  Even though it's cle=
arly not a 'defined term', and I will obviously not propose an RFC to ban '=
Controversial RFCs' as they're impossible to define ahead of time, simply p=
ut they are RFCs that create controversy.  Based on my analysis yesterday, =
I think there's a relatively easy way to spot them if you look at the numbe=
rs (for those reading this message out of context - bit.ly/php7rfcs), and I=
 believe we can come up with a mechanism to minimize them or outright avoid=
 them altogether.  It would come at a price - we would have to agree that i=
mproving the atmosphere on internals by focusing on ideas that are enjoying=
 widespread consensus is more important than approving any one particular i=
dea.

> The recent discussion on Antony's CoC RFC, has very little people/comment=
s
> trying to improve it, but instead trying to torpedo it because of "why do=
 we
> even need it? we're not 'toxic'" (again, paraphrased).

I don't see it that way. I think I provided very relevant feedback - that y=
es, called for a very substantial revision of the proposal and a removal of=
 a substantial part of it - but I still marked the concept of having a CoC =
as a good idea from the get go.  Separately, I think that if people think t=
hat a given proposal is a bad idea and cannot be improved - it's perfectly =
fine that they would voice their opinion.  Some ideas are just bad, and RFC=
s are often withdrawn or fail to pass.  Personally I don't think the CoC pr=
oposal is inherently bad - quite the opposite - but I think its implementat=
ion the way it's currently phrased is quite negative.  To be perfectly hone=
st, I'm offended that despite spending literally hours on providing feedbac=
k and making my case for why even the latest draft is problematic (and how =
I think it can be improved to reach consensus) - feedback that were complet=
ely respectful - I received no response from any proponent of the RFC.  The=
 same holds true for several other people - who provided relevant feedback =
which went ignored.  In fact, the response came as saying 'No more feedback=
 please.  My next email will be presenting a final draft, after which I'll =
go to a vote after the minimum allotted time'.

I think the current CoC RFC is a perfect example of a controversial RFC.  I=
t's creating controversy.  It doesn't matter if it's right or wrong.  The c=
hances of it hitting consensus (85-90% mark) seem very slim.  It might reac=
h 67%, I have no way to predict it - but having 9 supporters for every pers=
on thinking it's bad?  Doesn't sound very plausible based on the internals =
discussion so far.  Specifically the CoC discussion is also controversial f=
or another reason - it's using the RFC process for a purpose it was never d=
esigned to fulfill.  But I'd rather not discuss the specifics of the CoC RF=
C right now, and try to solve our fundamental problem instead.  A problem w=
hich even the proponents of that RFC aren't saying it's supposed to solve.=
=20

Another point to consider is that when as RFC authors, you have a 85-90% ba=
r to clear - you're much less likely to be ignoring substantial amounts of =
feedback and just pressing on to a vote, which is what's happening here.

> > Had we had a 90% bar, it does mean that STH wouldn't have made it into
> > the language, but it also means that we would probably not have the
> > discussion saga on internals either, and all of the bad vibes that
> > surrounded it.
>=20
> That however, makes it very easy for a vocal majority to torpedo everythi=
ng.

I believe you meant a 'vocal minority', but that's the wrong way to describ=
e it in my opinion - the right term is a substantial minority.  Vocal minor=
ity makes sense when we're talking about a handful of people, or even less =
than a handful, that are vocal well beyond their representation in the vote=
r base.  I do think we need to find ways to prevent a true vocal minority f=
rom shooting down ideas, and I proposed a couple which I actually think are=
n't that bad.  The problematic RFCs are the ones that generate a lot of int=
erest, with a lot of people having an opinion about them - but opposing one=
s.  RFCs that generate a lot of interest AND have close call votes are quit=
e uncommon.  Today, what happens is that these RFCs begin with large feedba=
ck threads, often heated, and they result in large voter turnarounds.  Once=
 the vote is over (whether it's approved or declined), it's a zero sum game=
 - the winning side is happy, the losing side is sad.  More importantly - w=
e've already paid the price in terms of making internals a tiny bit more un=
attractive to everyone - not just newcomers.

> I think this is only just going to cause more resentment to the few peopl=
e
> that tend to vote against nearly every RFC.

I think the mechanisms proposed - either a 2/3 majority until 50 votes and =
90% beyond that, or keeping the bar at 2/3 but having a 'double no vote' th=
at voters will be able to use very selectively (because of limited supply) =
- can prevent that from being an issue.  I'm sure people will be able to po=
ke holes in these ideas, but I believe they can be solved.

Again, the premise of this proposal is simple - do we care more about one p=
articular idea, or about focusing on the areas we all agree on?  For me it'=
s a no brainer, and if we agree the consensus is more important than any on=
e particular idea, I believe we can find the voting system to enforce it.

> But - it's an interesting theory.

Thanks!

Zeev