On 01/04/2016 03:06 PM, Anthony Ferrara wrote:
Hey all,
I have created a new RFC for the PHP Project to adopt the Contributor
Covenant as the official Code of Conduct for the project
https://wiki.php.net/rfc/adopt-code-of-conduct
Let me know what you think or if there are any concerns
Thanks
Anthony
Jumping back to the beginning of the thread as the tail of it at this
point has veered off onto a rather pathetic pseudo-anarchist rant-tangent...
I've had very mixed feelings about CoCs for a long time. Drupal went
through its own rather contentious CoC process a few years back, and I
was initially in the No camp. In the end, though, the devil is in the
details and I am +1 to a CoC as long as it's a well-written one that
doesn't jump to "innocent until proven guilty as soon as anyone thinks
they might be offended, then we burn the witch". Such CoCs do exist,
and suck, and we should have no part in them.
On the whole, I find the Contributor Covenant a good CoC model although
it is imperfect. My main issue, as noted by a few others and expanded
on in the RFC, is the confidentiality/anonymity involved. I am a firm
believer in the right to face one's accusers. (Yes, that "right" as
defined in the US constitution is legally only binding on US legal
bodies, and some may argue only the Federal government, but I firmly
believe that as a general principle it should apply universally.)
That's because the accused person MUST be allowed to present their
side/interpretation/perspective, and to do so effectively they need to
know what they're even accused of. Redacting the name of the accuser is
ineffective, as if enough context is provided for the accused to respond
at all it will, by nature, reveal the name of other people involved. If
not, then the accused cannot provide any meaningful response.
Not having anonymous complaints is exactly how we avoid (or at least
minimize) the "secret cabal/star chamber/people have it in for me" factor.
My other issue is that the RFC focuses on punitive measures rather than
corrective measures. The tone here is very important, as we want
everything related to a CoC to be cooperation-driven rather than
penalty-driven. (That was one of the biggest complaints against the
first draft of the DrupalCon CoC a few years back; the second draft,
which was adopted, was worded much much better.)
There is lots of prior art here, and I would strongly recommend reaching
out to the Drupal Community Working Group or its counterpart with other
major OSS projects for advice on how to strike a more positive spin.
While the ban-hammer is the obvious tool, it's rarely the best and other
approaches are often much more effective in the long run. (The Drupal
CWG is responsible for managing and enforcing the Drupal CoC. I'd be
more than happy to make introductions for anyone who is interested.)
So on the whole, +1 in concept but needs some work before it's ready.
To some of Stas' points:
1) Part of the point of a CoC is to signal that it's OK for someone to
come in. There doesn't have to be a problem, yet, for them to still be
valuable. They *could* be interpreted as "we have a problem and here's
part of the solution", but could also be "we want to take an affirmative
step before a problem happens". Hopefully the latter more than the
former...
2) To the claim that "we're all equal now", that's hogwash. :-) PHP
Internals may not have a formal structure or hierarchy beyond Release
Managers, but because it's a group of more than 2 people there is of
course an implicit, informal power structure. The best writeup on that
front would be:
http://www.jofreeman.com/joreen/tyranny.htm
(It's talking about the feminist movement of the 60s, but the concept
applies to just about every OSS project ever created. And any other
volunteer group since forever.)
A specifically named community working group / CoC Response Team /
whatever you call it is a way to explicitly separate the addressing of
misbehavior issues from that informal power structure, so avoid (or at
least minimize) people with more "karma" (informal term here) getting an
implicit pass. That sort of implicit tolerance has been very toxic in
other communities (c.f.
http://blog.randi.io/2015/12/31/the-developer-formerly-known-as-freebsdgirl/
for the most recent sad example). Having a formal process doesn't
guarantee it doesn't happen, but it helps reduce it and provides a way
to call out when it happens.
Again, having the mechanism in place before it becomes an issue is a way
to ensure it stays not an issue.
3) Stas, you claim that such a Response Team and process would be rarely
used. I will not comment on its likely workload, however, I would
submit that having a process to handle misbehavior that rarely if ever
needs to be called upon is perhaps the best ringing endorsement of a
community there can be. That is, if we do setup a Response Team or
whatever, and they are incredibly bored in the job and never contacted,
that's something to be proud of, not upset at wasted time.
(If they're bored because no one trusts them to bring an issue to them
in the first place then that's a very big problem but I'm trying to be
optimistic here.)
4) Yes, much will depend on who the people on that team are. That's
always the case. No process will protect you from incompetent people,
and no group of really good people can protect you from a broken
process. Additionally, I would note that there is absolutely zero
correlation between a person's coding ability and their conflict
resolution ability. That is, the people who are best for that role will
probably *not* be the top coders, and that's OK, and probably a good
thing. Separation of concerns. :-)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
