Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91170
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <BY2PR02MB2980991BC5A82BE60B75114ACD60@BY2PR02MB298.namprd02.prod.outlook.com>
References: <alpine.DEB.2.20.1602091208150.7348@whisky.home.derickrethans.nl>
	<BY2PR02MB2980991BC5A82BE60B75114ACD60@BY2PR02MB298.namprd02.prod.outlook.com>
Date: Tue, 9 Feb 2016 23:00:00 +0700
Message-ID: <CAEZPtU6JVFptaHwR7hc3OUcGem_qv5MkZrW7NmpYgrM423u88g@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Derick Rethans <derick@php.net>, PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] Contributor Guidelines, and Updates to Code of
 Conduct progress
From: pierre.php@gmail.com (Pierre Joye)

hi Zeev,

On Tue, Feb 9, 2016 at 8:08 PM, Zeev Suraski <zeev@zend.com> wrote:
>> 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 t=
ext.  I do have a number of issues/suggestions with it though (apologies fo=
r not doing this sooner - I was swamped in the last 3 weeks with travel & o=
ut of town visits):
>
>
> 1.  "Debate the technical issues, and never attack a person's opinion. Pe=
ople will disagree, so be it."
>
> I think this sentence is problematic.  Not that I'm pro-attacks, but opin=
ions - as ideas - should absolutely be up for scrutiny and debate.  What I =
think 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=
 even if they don't have any 'technical issues' in them.  It's the personal=
 attacks we should avoid.  And of course, the criticism should be to-the-po=
int - but the proposed text already covers that.
>
> We can consider adding another important part of the equation - "Don't co=
nsider critique of an idea you proposed as critique of you personally."  As=
 humans, we tend to do that, and we shouldn't.

I cannot agree more with you here.

> 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,=
 that cannot be made better (typically ones that stem from bad ideas, which=
 absolutely do exist as per the previous point).  These RFCs need to be sho=
t down.

However this is very very disturbing. While you smooth it a little bit
later, this sounds to me like something I would really prefer not to
see. It is not necessary related to what can be covered by these
documents but a recent past shows me that the "shot down" part is more
than detestable.

It is perfectly fine to consider a RFC as bad and state it openly (as
in on the mailing list). But there is a clear line that should never
be crossed when it comes to "shoot down" a RFC or an idea. This line
has been crossed a few times (64bit patches or the STH RFC for
example). And this is something I like to be covered to some extend.

I am not against private discussions, by any mean, if they are
fundamentally technical or goes in a friendly manner to try to get a
1-1 in-depth discussion. But some of these private discussions were
more about putting unacceptable pressure to request the authors to
cancel their proposals. This is in my opinion not acceptable, not even
remotely acceptable and it has to stop. It is even more critical when
these pressures are applied by well known leaders. We can disagree on
ideas, even define them as very bad, but if we do it privately to
avoid public backlogs of what is being said (for obvious or less
obvious reasons) then it became a serious problem.

> Moreover, there are cases when the person who is talented at finding hole=
s in things isn't necessarily talented at coming up with solutions.  Findin=
g holes (negative aspects) of RFCs is an exceptionally important task, and =
we don't want to silence people who find issues - only because they can't t=
hink of solutions for them.

Yes that's why the discussion period exists.

Also one problem we have now with the RFCs is feedback not being taken
into account because it does not match the author ideas. It forces
competitive RFCs for the exact same subject instead of having
different proposals grouped in one and accepted/rejected. It also
prevents other ideas, maybe better ideas, to get in because many
simply do not want to go through the pain of creating competitive
RFCs.

> What I think we should say instead:
>
> "When you disagree with a certain proposal, try to think whether there ar=
e 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=
 author to try and evolve the idea into a better one.  Only resort towards =
arguing against the RFC if you think it's a bad idea and you can think of n=
o ways to improve it.  When disagreeing..."

With the hope that "propose them to the RFC author to try and evolve
the idea into a better one", even as options to the given RFC, get
accepted, but it is sadly very rarely the case.

Thanks,
--=20
Pierre

@pierrejoye | http://www.libgd.org