Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:90137 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 78159 invoked from network); 5 Jan 2016 19:41:27 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Jan 2016 19:41:27 -0000 Authentication-Results: pb1.pair.com header.from=larry@garfieldtech.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=larry@garfieldtech.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.28 cause and error) X-PHP-List-Original-Sender: larry@garfieldtech.com X-Host-Fingerprint: 66.111.4.28 out4-smtp.messagingengine.com Received: from [66.111.4.28] ([66.111.4.28:51626] helo=out4-smtp.messagingengine.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D0/C2-12097-46C1C865 for ; Tue, 05 Jan 2016 14:41:26 -0500 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id D106420A5E for ; Tue, 5 Jan 2016 14:41:22 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Tue, 05 Jan 2016 14:41:22 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=2pkUu2+ufaiKK4A vphF1hXNrVus=; b=to9Xl0hXV55UgqOzMW1QE82Pu20LXu/vIqq6wOiGeVkMY5M WHj9pKWy4nDuGsBsBg4w/NBBm1xkJI/FDkr2rVbuNF6xOMuWxAKl6ktlJxDChGVM qzb5GiLI7zDJYovekS420rr+LBA6t/uV3Nb578/LZC1ImQ25qekfNwbev+N4= X-Sasl-enc: RT0gouS+tNfYaY+3Rjhb+/tKb05bvAoOj8iYm1wwnZkY 1452022882 Received: from Crells-MacBook-Pro.local (unknown [63.250.249.138]) by mail.messagingengine.com (Postfix) with ESMTPA id 7DA0E680125 for ; Tue, 5 Jan 2016 14:41:22 -0500 (EST) To: internals@lists.php.net References: <568AE803.1080209@gmail.com> <568B0C8E.3080206@eliw.com> <568B1041.1060601@gmail.com> <568B1DA8.3060908@gmail.com> <568BD0CA.7040909@php.net> <568BE845.2090102@php.net> <568BFF63.3080403@garfieldtech.com> <7995F3E4-D9BC-499C-9D62-EE804D3292EF@gohearsay.com> Message-ID: <568C1C62.3060808@garfieldtech.com> Date: Tue, 5 Jan 2016 13:41:22 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct From: larry@garfieldtech.com (Larry Garfield) On 1/5/16 1:03 PM, Sara Golemon wrote: > On Tue, Jan 5, 2016 at 10:27 AM, Kevin Smith wrote: >> Much of the argument in favor of a code of conduct seems to be centered around the desire to send a message to the wider developer world that we’re a welcoming community that doesn’t look kindly on poor treatment of others. If that’s the goal, rather than the goal being to punish or censor people who violate our own values, why do we need a response team with the power to ban? >> >> If a person's treatment of others truly warrants banishment, then as Zeev noted the RFC process is already perfectly suited for that. As far as I’m concerned, the absolute greatest power the response team should be given is the power to issue a censure. If sending a message is the goal, that’ll do it. >> >> > I'll chime in on this, since you and I had a quite pleasant and > productive conversation last night. I believe we agreed that the > original draft was over-focused on punitive measures and not enough on > low-impact mediation. > > I imagine, because I love all you guys (and gals), that the volume of > traffic to a response team would be low to begin with. I further > imagine, since you're all such a great bunch of lads (and lasses), > that the vast majority of those complaints would be resolvable with > some gentle mediation. That's a good focus for the CoC, and I would > love to bring us to that point. (Sorry if you've already addressed > this Anthony, I haven't read your updates yet, it's been a busy > morning). > > I said it in a prior email, but I'll repeat it. I see it like the > security@ list. A place to send issues that don't necessarily bear > airing in public. That's good for both the accuser AND the accused. > A tiny layer of discretion to ease what may be a tense issue. > > I don't, however, agree that the response team should be entirely > toothless. As a *last resort*, a (no more than) 7 day ban to act as a > cooling off period isn't "vast sweeping powers", it's a band-aid for a > situation that's gotten out of control. A situation that demands the > wider community's attention, because it's become unacceptable. We can > define the limits of these powers (again I've said this in a previous > email). > > Worried about abuse of temp-bans? Don't think a stringent requirement > of justification is enough? How about the accuser must suffer an > equal ban? By the time it's come to the point where action must be > taken, the problem has escalated to the point where privacy of the > accused won't be maintainable anyway (due to evidence requirements). > Turn the temp-ban into a cooling off period. Because honestly, do we > have mustache twirling ne'er-do-wells? Or do we have passionate people > who get worked up into a lather and sometimes cross a line? > > As someone who has crossed that line more than once, I hope you'll > trust it's just the latter. > > -Sara I agree with Stas (previous email) that a bad CoC can backfire. I'd go as far as saying that a bad CoC (either one that is so toothless as to be a lie or one that is so draconian that everyone lives in fear of it) is worse than no CoC at all. That is, I think, the point of this discussion: Make sure that a CoC is adopted that is good and has a positive impact, not bad with a negative impact. Which is where I agree with Sara: A good CoC should be positive and focused on conflict-resolution, not on punitive measures. So let's build a good conflict-resolution-oriented CoC and process rather than a ban-hammer-mechanism. Also, recall that this is not a for-all-time definition. CoCs can and should evolve over time, as should the process around them. Disclosure: I've been through Drupal's Community CoC, the DrupalCon CoC, and multiple rounds of CoC-esque discussion in a 20-year old online RPG club I used to help run. I've been around this block more than once. Reference material: Drupal's Community CoC: https://www.drupal.org/dcoc was derived originally from the Ubuntu Community CoC: http://www.ubuntu.com/about/about-ubuntu/conduct The DrupalCon CoC was more contentious until it was rewritten to be more positive-oriented (less "we don't" and more "we do"): https://austin2014.drupal.org/code-of-conduct.html The main author of the DrupalCon CoC, George DeMet, pointed me at the Django CoC as another good model: https://www.djangoproject.com/conduct/ Sara, Stas, Anthony, are you open to talking with George? (Disclosure: Besides being on the Drupal CWG, George is also my boss. ) -- --Larry Garfield