Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91145
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 207.46.100.113 as permitted sender)
To: Derick Rethans <derick@php.net>
CC: PHP Developers Mailing List <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [VOTE] Contributor Guidelines, and Updates to Code of
 Conduct progress
Thread-Index: AQHRYzYya/0aCsZ6gUKiKrT9naEgWJ8jp3Mw
Date: Tue, 9 Feb 2016 13:08:58 +0000
Message-ID: <BY2PR02MB2980991BC5A82BE60B75114ACD60@BY2PR02MB298.namprd02.prod.outlook.com>
References: <alpine.DEB.2.20.1602091208150.7348@whisky.home.derickrethans.nl>
In-Reply-To: <alpine.DEB.2.20.1602091208150.7348@whisky.home.derickrethans.nl>
Accept-Language: en-US
Content-Language: en-US
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: 09 Feb 2016 13:08:58.0595
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 32210298-c08b-4829-8097-6b12c025a892
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR02MB300
Subject: RE: [PHP-DEV] [VOTE] Contributor Guidelines, and Updates to Code of
 Conduct progress
From: zeev@zend.com (Zeev Suraski)

> Feel free to reply here with suggestions, comments, etc.

I think this is a pretty good start and I can stand behind most of this tex=
t.  I do have a number of issues/suggestions with it though (apologies for =
not doing this sooner - I was swamped in the last 3 weeks with travel & out=
 of town visits):


1.  "Debate the technical issues, and never attack a person's opinion. Peop=
le will disagree, so be it."

I think this sentence is problematic.  Not that I'm pro-attacks, but opinio=
ns - as ideas - should absolutely be up for scrutiny and debate.  What I th=
ink we should say instead is this:

"Debate the ideas, never attack the person holding them."

Criticizing ideas is absolutely fine, and it's healthy.  Ideas can be bad e=
ven if they don't have any 'technical issues' in them.  It's the personal a=
ttacks we should avoid.  And of course, the criticism should be to-the-poin=
t - but the proposed text already covers that.

We can consider adding another important part of the equation - "Don't cons=
ider critique of an idea you proposed as critique of you personally."  As h=
umans, we tend to do that, and we shouldn't.

2.  "Suggest improvements to the RFC, don't just shoot it down."

I disagree that this is a Good Thing.  There are most certainly bad RFCs, t=
hat cannot be made better (typically ones that stem from bad ideas, which a=
bsolutely do exist as per the previous point).  These RFCs need to be shot =
down.  Moreover, there are cases when the person who is talented at finding=
 holes in things isn't necessarily talented at coming up with solutions.  F=
inding holes (negative aspects) of RFCs is an exceptionally important task,=
 and we don't want to silence people who find issues - only because they ca=
n't think of solutions for them.

What I think we should say instead:

"When you disagree with a certain proposal, try to think whether there are =
changes that can be made to the RFC that will enable you to support it.  If=
 you come up with such improvements, respectfully propose them to the RFC a=
uthor to try and evolve the idea into a better one.  Only resort towards ar=
guing against the RFC if you think it's a bad idea and you can think of no =
ways to improve it.  When disagreeing..."

3.  s/Don't use hyperbole/Try avoiding hyperbole  - both because hyperbole =
is difficult to define, and because people respond better to asking vs. dem=
anding.

4. s/Do not post when you are angry/Try avoiding posting when you are angry=
 - for similar reasons

5.  I think the 'max 2 lines email signature' requirement is a bit archaic.=
  Who cares?  Do we expect people to change their signature especially for =
internals?  Not important, but if we're nitpicking :)

Note that we have a serious issue with voting process on these topics, whic=
h is probably not much of an issue for this document (for which we should b=
e able to garner a very strong majority, I believe, and you already said yo=
u consider the vote to be non-binding) - but will definitely be an issue fo=
r any CoC.  But that's something we should discuss separately.

Thanks for working on this!

Zeev