Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90184
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.50 as permitted sender)
To: Anthony Ferrara <ircmaxell@gmail.com>,
 "internals@lists.php.net" <internals@lists.php.net>
References: <CAAyV7nFbngZ42qzbSFyveH+vsyir9QNtMJq8H=u9VqTBVBv5Og@mail.gmail.com>
 <CAAyV7nGzsuhDSgenmLUjWPYiNfamcqCgvXpM4Sb30VECpTrHpQ@mail.gmail.com>
Message-ID: <568C9ED7.30504@gmail.com>
Date: Tue, 5 Jan 2016 20:57:59 -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: <CAAyV7nGzsuhDSgenmLUjWPYiNfamcqCgvXpM4Sb30VECpTrHpQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> In response to significant feedback here and elsewhere, I have
> expanded the text of the RFC significantly. It now includes the text
> of the Contributor Covenant 1.3.0 as well as including verbage about
> updating it requiring an RFC.

Thanks for improving the RFC. It is already much better than the initial
variant, though I think more improvement is needed. As I wrote in
previous emails, I'd like mode of what we want than what we hate. We
already seen example from Drupal, here's one from Python:

https://wiki.python.org/psf/CodeOfConduct

I agree with having specific point of contact to turn to is beneficial
and it should probably be featured on the same page as the text above. I
am not sure I understand why list should be unarchived - while I see why
*public* archive is not good, why not have private archive accessible to
the members? After all, any member can archive all the emails anyway
(and people with accounts like gmail probably routinely keep mails for
years without deleting them). But having the established one avoids the
situation where there's a problem with one member of the list and it
turns to "she said, he said" situation with no proof of anything.

> I included a vote requirement for course of actions of 4/5 of the CoC team.

Good!

Additionally, I would propose naming this team something like Mediation
Team or Conflict Resolution Team, to emphasize that its primary role to
find the best resolution of issues and not to bash people over the head
with codes. Bikeshedding on the name along these lines is welcome :)

> This Code of Conduct applies both within project spaces and in public
spaces when an individual is representing the project or its community.

I think this is way too broad. "individual is representing the project
or its community" can be construed to mean basically anything - if a
person is known in the community, any of their actions, even without
relation to the community functions, can always be construed as
"representing", especially by people with an ax to grind. We'd get
people complaining "how could prominent member of this project vote for
that vile politician X" and "how could prominent member of this
community support that awful law Y" and we definitely not want to go there.

> Process For Incidents

I think the process should be amended to emphasize that the first course
of action for the team should be to try and find amicable resolution of
the issue (I imagine there are many established mediation techniques
that can be applied and referenced, we're not exactly pioneers here :)
and only when it proves futile (or misconduct is so egregious that it is
obvious it is too late for mediation) the team would take further
action. I.e. one does not need a vote to help diffuse the conflict.

> I also included content about the "Reasonable Person Test", explicitly
> stating that it shall be assumed that both parties are acting as
> reasonable people until proven otherwise by significant evidence. It

That is good. I think the principle of assuming good faith leads to
better results.

> I also made it explicit that potential actions should be a last
> resort, and that the CoC team should make every reasonable attempt to
> defuse the situation without having to resort to "punishment".

Excellent!

> Either party may appeal an action by raising the concern to
internals@php.net.

That would be impossible if one of the parties is banned from internals.

> All incidents are to be kept in the strictest form of confidentiality

I still think the secrecy bias is unhealthy. I remember how much
controversy was produces by the supposedly private discussions of
certain technical questions and RFCs. Imagine how much more heat would
be generated if the discussion in question has a conflict as a starting
point. The potential for toxic suspicions and distrust is enormous.

> Additionally, I added a line specifying that bans (temporary or
> permanent) should only be used in egregious cases.

I'm not sure I still comfortable with notion of these bans, especially
the one which bans somebody for the duration of RFC discussion in which
their case is discussed.

> I added a section on transparency, Conflict of Interest (though this
> needs expanding) and accountability (giving internals@ the ability to
> "overturn" any action by the CoC team with a vote of 50%+1). I also
> made it explicit that accused people have a right to confidentiality
> as long as no action is taken by the team.

I am a big fan of transparency, but here in particular I'm not sure that
every mediation attempt should be indeed reported. Maybe if no further
escalation was required, less publicity is better. We need to be careful
here, as many things could be resolved in private more efficiently if
public displays and egos are less involved :) This is another thing
where over-legislation is bad, as there's a lot of common sense needed
and you can't legislate that.

> own custom one, there are two reasons for this. First, it's a standard
> that's been adopted by a number of significant scale projects. Second,

I completely disagree that Contributor Covenant's text is any kind of
"standard". I've seen a number of CoCs, and it's not the worst (though
their homepage is... meh) but also not the best, and certainly not only.
Yes, a bunch of projects adopted it, many out of convenience or to mimic
bigger ones - I've seen a number of project references there that have
single contributor and like 5-6 commits, so these numbers say nothing.
But we're not some random 20-line tool which 5 people use. So we can't
just take a cookie-cutter template and adopt it, disregarding our
community specifics. It's much better for us to think on our own and to
have something that suits us, then to run behind 10000 copy-pasted
statements to which their authors probably gave no more than 10 seconds
of thoughts. I don't blame them - if you have 20-line utility to which
you alone ever commit, spending time developing code of conduct or even
thinking about it too long is silly. But for us, it is not.

> from one. In this case, we simply do not know if or how many
> contributors we may have lost due to incidents covered by a CoC. Even

I'm growing tired of this argument. We also do not know how many
contributors we may have lost because we do not sacrifice a goat monthly
to the Flying Spaghetti Monster, and we do not know how many
contributors we may have lost because we do not publish a video of the
committer dancing haka before each commit. The argument from ignorance,
aka "you can't prove X is not magical, therefore we should do X" is one
of the worst arguments in existence, and it would be really good if we
stopped using it in rational discussion.

> if that number is 0, does that mean it's not worth installing one to
> prevent it in the future?

Especially if the argument is then backed up with "regardless if this
argument is true or false, we should do X anyway". If we should do it
anyway, why bother with discussing imaginary scared contributors?

-- 
Stas Malyshev
smalyshev@gmail.com