Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90399
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.173 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
In-Reply-To: <5690130A.9050801@garfieldtech.com>
Date: Fri, 8 Jan 2016 14:06:42 -0600
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <C152F025-783F-4A82-B49A-BF38AD7DAA27@gmail.com>
References: <BE0EB5B804BC488AAD1344BF9D3B9277@gmail.com> <6D.39.21755.3576D865@pb1.pair.com> <1AD1B991-A3E5-4D6C-A532-5F0FCCC2ED61@gmail.com> <CAObuZdtKyJXVEAtJzvZENf+Da6S+BFCnXaErvmiHJXen9DCDmA@mail.gmail.com> <568D7C5D.9020405@php.net> <CAAyV7nFYYxZELZhgo_wrhr9u2+Lww1jQAw+3O=fGqLJJdg7GkA@mail.gmail.com> <1e6a13607a3a1c8b20a4649f8a5ef767@mail.gmail.com> <CAEZPtU5BaogkrJ4H9o1x9ENWXOVqnAye8Oh535aTHOefMuJz6w@mail.gmail.com> <3AB5AA82-4F17-40C3-B8B5-33697A8DBEC2@gmail.com> <CAEZPtU6T14yr8UN1F0goY=7sme-iKgXLECSL7yiAqFLf_xPchw@mail.gmail.com> <FD56BF25-0825-4666-AEF9-06996E59C514@gmail.com> <CAEZPtU7nNuEQehisOZK3nC4AuafrahQbvLgZOGteR1jt4cWV_w@mail.gmail.com> <B1697F0F-883C-4D49-8CB6-4DF152662886@gmail.com> <8D90A4F6-4E3E-4283-B8E3-152E4707EF4E@moonspot.net> <568F4E81.1020205@garfieldtech.com> <2732F2A4-51F7-42CC-A7E7-1EC7B26CDF97@gmail.com> <568FFD08.1080104@garfieldtech.com> <2718DA23-C14B-427A-9FE8-C86918BAA00C@gmail.com> <5690130A.9050801@garfieldtech.com>
To: Larry Garfield <larry@garfieldtech.com>
Subject: Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct
From: pmjones88@gmail.com ("Paul M. Jones")


> On Jan 8, 2016, at 13:50, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> On 1/8/16 12:31 PM, Paul M. Jones wrote:
>>> On Jan 8, 2016, at 12:16, Larry Garfield <larry@garfieldtech.com> =
wrote:
>>>=20
>>> On 1/8/16 11:28 AM, Paul M. Jones wrote:
>>>>> On Jan 7, 2016, at 23:52, Larry Garfield <larry@garfieldtech.com> =
wrote:
>>>>>=20
>>>>> Do you think we can find 5 people in the PHP community that we can =
trust to make fair decisions (NOT that we would always agree with, but =
that are fair) that don't fall too far into "thought policing", in *any* =
direction?  If not, then the community is already lost beyond all hope =
and we should all just give up now.  I do not believe that to be the =
case, at all.
>>>> Too long spent in a position of power, and even the most fair can =
become unfair.
>>>>=20
>>>> As I have suggested before: *if* there is to be a response team, =
let it be randomly selected on per-reported-incident basis from the pool =
of voters. Then there is no possibility of a charge of continuing bias, =
and it distributes power among the pool, instead of concentrating it =
into a few members.
>>>>=20
>>>> Proponents of the response team: thoughts?
>>> Randomly selected: Absolutely not.  I wouldn't randomly select =
someone to make Ultimate Decision(tm) on a technical RFC, either. But if =
a question about, say, a parser bug came up there are absolutely certain =
people that I would trust with that question more than others, and defer =
to their analysis/opinion more readily.
>> Certain people *you* would trust more than others, but that *others* =
would not trust more.
>>=20
>> Also, this is a social/political realm, and not a technical realm; =
would you not trust, say, a randomly-selected jury to hear and decide on =
a case? If not, why not?
>=20
> As many people, including both you and I, have said, we don't want to =
focus on the "jury" aspect.

(/me nods)

If there must be a response team, I would prefer the "mediator" =
approach, as you note.

However, the RFC as I last saw it is not a "mediator" approach, but a =
"judicial" one. If it is to be a "judicial" approach, my suggestion =
stands. If/when the RFC changes to a "mediator" approach, I will change =
my suggestions to fit the modified RFC.


--=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