Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90756
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.170 as permitted sender)
To: Derick Rethans <derick@derickrethans.nl>,
 PHP Developers Mailing List <internals@lists.php.net>
References: <alpine.DEB.2.20.1601201851500.3314@whisky.home.derickrethans.nl>
Message-ID: <56A01AE5.2040100@gmail.com>
Date: Wed, 20 Jan 2016 15:40:21 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.20.1601201851500.3314@whisky.home.derickrethans.nl>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> I've decided to re-propose the CoC RFC. There are many reasons for it, 
> but there are a few points I want to make.
> 
> I strongly believe that a Code of Conduct is required. The amount of 
> toxic behaviour on this list is in my opinion unacceptable. It drives 
> people away, it certainly did. It is also one of the reasons I am not 
> nearly as active as I used to be.

Thanks for continuing the discussion. I'd like however to point out that
one of the major points of contention, as I see it - that it is not at
all clear how having CoC prohibiting things like "the use of sexualized
language" and "trolling", would help with "toxic behavior". I want to be
very clear, because I feel this concern is not being understood, so I
will try to outline it as detailed as I can, please excuse the verbosity:

1. I do not think literally anybody wants to see trolling or sexual
language attacks, or harassment, etc. on the list. I think we all agree
this is unacceptable.

2. I think most of the people here know that the list has been not the
friendliest place ever, and most of the people here would like to
improve that.

3. I do not think we do have now or ever had a significant problem with
behaviors described by "Code of Conduct Text". I think the problem
described may be caused by other set of behaviors, not covered by "Code
of Conduct Text".

4. Given that, it is not clear to me, and apparently some other folks
too, how banning those (as universally agreed) despicable behaviors is
going to lead to any improvement on the matter of "toxic".

5. Since so many people somehow did not understand that, judging by
their comments, this does not mean anybody thinks it is OK to behave
that way (see 1). It means that it appears we are trying very hard to
fix not the same place that is claimed to be broken.
Now, it can be that *both* places are broken, or that the fix can be
applied as a preventive measure - and both are fine. But arguing "we
have problem X therefore let's apply fix for a different problem Y"
sounds strange to me.

I think clarifying that matter would help.

Also, there was a complaint that there has been too much critique and
not enough constructive proposals. I think there is some truth to that,
as it is much easier to find bugs than to develop things, and much more
people submit bug reports than fix them. This is natural, but this
certainly could use improvement. In that spirit, I would like to
reiterate the proposal of handling CoC matters that I personally think
would be the best. This is my personal approach, so please feel free to
amend, criticize and disagree.

1. Make a values statement, along the lines of:
https://www.drupal.org/dcoc
https://www.djangoproject.com/conduct/
https://www.freebsd.org/internal/code-of-conduct.html
https://meta.wikimedia.org/wiki/Grants:Friendly_space_expectations

This document should emphasize behaviors we want to achieve and
reinforce, not be just a catalog of behaviors we hate.

In this document, as one paragraph, include "unacceptable behavior"
statement from current RFC, verbatim or suitably modified (that of
course does not preclude including other parts of it in other paragraphs).

"Constructive Collaboration Guidelines" probably should be part of this
document too - and be stated before the unacceptable part. I know it
sound like nitpicking but I think tone of the documents is important and
if we start with negatives (even by rejecting them) it sets different
tone than if we start with positive. It's one thing to welcome people to
your house with "Welcome, friend, feel at home!" and another with
"Please don't steal my wallet and don't kick my dog!"

2. Create a conflict resolution team whose stated purpose is to resolve
conflicts (note: not punish or exclude!) which impact the project and
impede or disrupt the collaboration.

3. Separately from the document above, have a conflict resolution
policy, which describes how the CRT above is elected, how it resolves
issues, what are the confidentiality guidelines, what are processes for
creating bans & appeals, etc.

I know not everybody agrees, but I think it is much more beneficial to
have this in a separate document and if possible, as a separate RFC,
since discussion about it is substantially different from (1) and
partially from (2) - principal agreement on having such team is much
more important, IMO, than figuring out how long it can ban people for.

That would also make discussion a bit more manageable, as discussing at
the same time two different things: do we want CoC and the particular
details of CRT behavior we want. I think separating these discussion
would allow us to emphasize things we agree on and formalize them
quickly, and hash out the details without the concern that small
disagreements would derail the whole process.

If this looks good to anybody, I can take the time to actually arrange
the texts - though English not being my naive language, I am not the
best person for copy-writing. But I assume somebody could fix it up
afterwards :)
-- 
Stas Malyshev
smalyshev@gmail.com