Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90575
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nFbngZ42qzbSFyveH+vsyir9QNtMJq8H=u9VqTBVBv5Og@mail.gmail.com>
References: <CAAyV7nFbngZ42qzbSFyveH+vsyir9QNtMJq8H=u9VqTBVBv5Og@mail.gmail.com>
Date: Tue, 12 Jan 2016 21:28:29 +0000
Message-ID: <CALwr1GkpmTssGvRx=Wjcu47+K0seZ6Spqm7A-2rPR0R96u2UGw@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct
From: padraic.brady@gmail.com (=?UTF-8?Q?P=C3=A1draic_Brady?=)

Hi all,

I've already written a blog on the topic, so needless to say I have no
objections personally to seeing a Code of Conduct. Reading the current
draft RFC, I did see a few potential issues which I'd like to raise on
the specific text used insofar as it's starting point.

1. It should probably be made explicit that the Conflict Resolution
Team is uniquely responsible for determining what is or is not
"unethical or unprofessional conduct" subject to overview by Internals
(via the appeals process). It's already implied, but this may cover
any spurious claims that they lack the authority to do so. It also
recognises that what constitutes unethical or unprofessional conduct
needn't immediately be defined in a 100 book volume. Also see pt. 6
below.

2. The phrase "representing" strikes me as difficult to assess and is
open to interpretation. Examples towards the end of the RFC clarify
this better, but may be insufficient. I'd be more in favour of an open
ended approach, centered on whether or not the subject of a complaint
currently utilises the resources (list, git, etc.) of the project,
i.e. where the project actually has recourse to punitive measures.
This would encompass scenarios where there's no direct representation
in evidence but the conduct in question is still linked to the PHP
project through more indirect means. It's all too easy to imagine
scenarios where harassment is designed to avoid the appearance of
representing the project despite it obviously being linked to the
project by context.

3. I'd like to see the Conflict Resolution Team framed as a group
whose members will, volunteers allowing, be diversified.

4. The process for reported incidents does not mention specific
timelines. There's also no mention of immediate relief measures. I'd
find it troubling if the timeline turned into weeks, and the subject
of a complaint continued their actions unabated and without
consequence. If the team can make a rapid provisional determination,
it should be explicitly allowed for them to request the accuser cease
any objectionable actions under question while a final determination
is pending.

5. It should be made explicit that the accused is definitely not
allowed to disclose the identity of their accuser, directly or
indirectly, without consequences. I'll leave it open to the floor as
to what extent this could be applied, e.g. in scenarios where it's
fundamentally necessary in order for the accused to collate evidence
in their defense.

6. It's easier to enumerate what to do, then what not to do. Perhaps
fold in text from the likes of the Debian COC as a supplementary or
inline statement of accompanying principles?

Regards,

Paddy "But I Only Voted That One Time" Brady

--
P=C3=A1draic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com