Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91210
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.178 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
In-Reply-To: <alpine.DEB.2.20.1602091208150.7348@whisky.home.derickrethans.nl>
Date: Thu, 11 Feb 2016 11:16:22 -0600
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <D770F263-EF85-42D5-BCD5-FBB6E65EEEE1@gmail.com>
References: <alpine.DEB.2.20.1602091208150.7348@whisky.home.derickrethans.nl>
To: Derick Rethans <derick@php.net>
Subject: Re: [PHP-DEV] [VOTE] Contributor Guidelines, and Updates to Code of Conduct progress
From: pmjones88@gmail.com ("Paul M. Jones")

Hi Derick,

> On Feb 9, 2016, at 06:33, Derick Rethans <derick@php.net> wrote:
>=20
> Hello!
>=20
> Things have quieted down around the Code of Conduct and Contributor=20
> Guidelines process

For my part, at least, things are in "hibernation" until the wiki is =
updated with the new draft. Meanwhile:

=20
> - I had a call with the Drupal Community Working Group - as suggested =
by=20
>  Larry Garfield. Stanislav was on the call as well.

Is there a transcript or recording of the call? I'm very interested to =
know what transpired.


> - We should be reluctant to limit the scope of the Code of Conduct and=20=

>    Contributor Guidelines.

What is the reasoning behind this?


>  - A Code of Conduct without *any* 'teeth' would not be beneficial.

Why was that?


>  - We should start with suggesting/nominating people for the Mediation=20=

>    Team *before* deciding on the procedures and guidelines that=20
>    they should mediate around. The underlaying reason is that if the=20=

>    team is known upfront, there ought to be more understanding for the=20=

>    general developer community. Or in other words, there should be no=20=

>    reason that "I would only put my friends on it".

I think that presumes the people making up the Team will be present for =
all time thereafter, and never replaced. Indeed, it reinforces the idea =
that the political persuasions of the Team members will be the =
determiner of how the Code is enforced, if one is ever adopted. Since we =
cannot know in advance who will be in place *after* the first Team, I =
opine the rules should not be Team-member-dependent.


>    I do however have a few people in mind that I will reach out to=20
>    privately, to see whether they are interested. If you have any=20
>    suggestions for people that you consider reliable, considerate, and=20=

>    empathic, please reach out to them yourself, or let me know and I=20=

>    will.

I'm reliable, considerate, and empathic toward accused persons.  Does =
that count?


>  - I combined the three bits of text around mailinglist posting=20
>    guidelines into the Contributor Guidelines=20
>    =
https://github.com/derickr/php-community-health/commit/7c55d1dd407524cdab5=
93b885e6b3101bf590769
>=20
> I feel that the "Contributor Guidelines" are now in a reasonable shape=20=

> to do a quick poll to gauge acceptability. As this is not a formal RFC=20=

> vote, it's simply done through an online poll:=20

(The poll was later moved to the wiki at =
<https://wiki.php.net/adopt-code-of-conduct/guidelines>.)

While the narrative itself is rather generic, there are several problems =
with the Guidelines. Others have mentioned some of them in various =
replies to this thread.

For me, the biggest problem is that the Guidelines presume that every =
RFC can be made into something useful and/or desirable. There is no =
allowance made for declining an RFC as unworkable or unacceptable from =
the beginning, politely or otherwise; for example, something that is =
against the "vision" (however interpreted) of PHP in the first place.  =
Some things are best rejected out-of-hand at their beginning. Some may =
not see that as "constructive"; but then, what is "constructive" depends =
on what you construct. Derick, can you imagine there might ever be a =
time when an RFC should be turned down on its face? If so, in which =
cases do you think that would apply? If not, why not?

Second, the Guidelines lack definitions. They say, "Debate the technical =
issues, and ideas behind them, but never attack the person holding =
them." Derick, what does "attack" mean in this context?  In lieu of a =
definition, do we have an actual example from PHP-Internals that shows =
an "attack" in that sense? If there is, it should be linked. If there is =
not, then why do we think "attacks" of this kind are a problem to be =
addressed?

Finally, these are Guidelines, but for whom? Is their violation =
actionable? If so, by whom, and in what circumstances? If not, then the =
Guidelines should say so.

I have other issues, but those will do for now.

--=20
Paul M. Jones
pmjones88@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php