Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90304
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <BE.70.21405.A00CE865@pb1.pair.com>
To: internals@lists.php.net
References: <CAAyV7nFbngZ42qzbSFyveH+vsyir9QNtMJq8H=u9VqTBVBv5Og@mail.gmail.com>
 <CAAyV7nHrip8Ljxjdi2DiGbcnXxY9JK+pN+LCwYKqsjJNvEyUrg@mail.gmail.com>
Date: Thu, 7 Jan 2016 19:44:06 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0)
 Gecko/20100101 Firefox/42.0 SeaMonkey/2.39
MIME-Version: 1.0
In-Reply-To: <CAAyV7nHrip8Ljxjdi2DiGbcnXxY9JK+pN+LCwYKqsjJNvEyUrg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [RFC] [Draft] Adopt Code of Conduct
From: ajf@ajf.me (Andrea Faulds)

Hi Anthony,

I have some concerns about the new wording.

Anthony Ferrara wrote:
>
> * The process was altered to focus on defusing and mediating rather
> than punitive. Additionally, it is made clear that punitive action in
> any form shall be a last resort.
>

Making it always a "last resort" worries me, as this is not an 
appropriate response to all situations. In some cases it is necessary to 
immediately take action. However, the actual RFC text says 'every 
reasonable attempt', so this does give some discretion - I presume this 
means that where it would not be 'reasonable' to act otherwise, the team 
could indeed take immediate action.

>   * Temporary bans shall not include internals@ to allow for appeals
> and conversation around the incident to be fair to both parties. This
> is under the assumption that behavior on internals@ remains civil as
> judged by the overall community.

I'm not sure this would work out well in some situations. If someone has 
been hot-headed and needs to cool down, allowing them to continue that 
behaviour, rather than forcing them to cool down and consider their 
actions, does not seem wise. If someone has publicly used the list to 
harass another person, allowing them to continue harassing them on-list 
does not seem wise. If someone has used the list to publicly post 
someone's personal information, or perhaps outright slander, allowing 
them to continue doing so, abusing the inherent permanence of everything 
posted to the mailing list, does not seem wise.

In fact, this sounds like a bad idea for all the examples of 
unacceptable behaviour that the Contributor Covenant lists.

I understand the intent of what you're doing here, but it naïvely 
assumes that every situation can be dealt with through mediation. This 
is, at best, only possible in relatively minor incidents where both 
participants are acting in good faith.

>   * Added a quarterly Conflict Resolution Team report posted to
> internals to summarize all activity

No objections to this.

>
>   * I added a few of examples of when the CoC should apply outside of
> the project, and what constitutes "representing the project". These
> are not meant to be exhaustive, but intended to communicate the
> "spirit" of representing.
>

These seem perhaps too specific. It appears to say that the PHP project 
does not see a problem with its members harassing anyone inside or 
outside the project, so long as they don't explicitly identify 
themselves to the project within the conversation.

> Again, all of this is up for discussion. I am simply expanding here to
> better clarify and codify what my intent was here. The thing I want to
> communicate is the spirit rather than the specifics.

The RFC is getting longer and longer, and I think excessively 
complicated. I don't think that trying to satisfy all critics will not 
result in a more effective RFC. For example, people who object to 
moderation will not be placated by stipulations that the moderation be 
focussed on mediation, and if we do become mediation-focussed, we risk 
failing in situations where mediation is not a reasonable option.

The RFC is now more than ten times the length of the Contributor 
Covenant, which the RFC itself incorporates. It's also partially 
redundant. The Contributor Covenant itself covers how to deal with 
violating it:

 > Project maintainers have the right and responsibility to remove, edit,
 > or reject comments, commits, code, wiki edits, issues, and other
 > contributions that are not aligned to this Code of Conduct, or to ban
 > temporarily or permanently any contributor for other behaviors that
 > they deem inappropriate, threatening, offensive, or harmful.

 > By adopting this Code of Conduct, project maintainers commit
 > themselves to fairly and consistently applying these principles to
 > every aspect of managing this project. Project maintainers who do not
 > follow or enforce the Code of Conduct may be permanently removed from
 > the project team.

 > This Code of Conduct applies both within project spaces and in public
 > spaces when an individual is representing the project or its
 > community.

 > Instances of abusive, harassing, or otherwise unacceptable behavior
 > may be reported by contacting a project maintainer at [INSERT EMAIL
 > ADDRESS]. All complaints will be reviewed and investigated and will
 > result in a response that is deemed necessary and appropriate to the
 > circumstances. Maintainers are obligated to maintain confidentiality
 > with regard to the reporter of an incident.

This is succinct and I doubt we really need much more than this. We need 
to designate who should handle these reports (the code of conduct team, 
in this case), and we might need to mention a bit about process, but do 
we really need anything else? Elaborating how the enforcers should be 
reasonable doesn't mean the enforcers will be any more or less 
reasonable. Having two paragraphs on confidentiality which contradict 
the code of conduct itself misleads people who do not see the RFC.

I do wonder if we're really going anywhere here.

Thanks.
-- 
Andrea Faulds
https://ajf.me/