Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:91157 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 80520 invoked from network); 9 Feb 2016 15:11:57 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Feb 2016 15:11:57 -0000 Authentication-Results: pb1.pair.com header.from=me@mprelu.de; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=me@mprelu.de; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain mprelu.de from 74.201.84.163 cause and error) X-PHP-List-Original-Sender: me@mprelu.de X-Host-Fingerprint: 74.201.84.163 sender163-mail.zoho.com Received: from [74.201.84.163] ([74.201.84.163:25243] helo=sender163-mail.zoho.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 27/17-39202-BB10AB65 for ; Tue, 09 Feb 2016 10:11:56 -0500 Received: from [192.168.0.5] (5ec1ae50.skybroadband.com [94.193.174.80]) by mx.zohomail.com with SMTPS id 1455030712278256.35414040063824; Tue, 9 Feb 2016 07:11:52 -0800 (PST) To: internals@lists.php.net References: <56B9F00B.5020305@mprelu.de> <56B9F865.5000005@gmail.com> Message-ID: <56BA01B5.3050303@mprelu.de> Date: Tue, 9 Feb 2016 15:11:49 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B9F865.5000005@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Zoho-Virus-Status: 1 Subject: Re: [PHP-DEV] [VOTE] Contributor Guidelines, and Updates to Code of Conduct progress From: me@mprelu.de (Matt Prelude) Hi, On 09/02/16 14:32, Rowan Collins wrote: > Having procedures for violation and not using them could still have > value. The most famous example of this is surely nuclear weapons, > which are frequently cited as a deterrent, not intended for actual use. > > A less violent example in the UK would be the phrase which came up > when arranging a coalition government, "avoid embarrassing the Queen" > - the Queen has the constitutional right to appoint a Prime Minister, > but forcing her to do so would be a major failing of the normal > processes. Her constitutional value lies, paradoxically, in her not > exercising any of her constitutional powers, because it forces people > to negotiate a solution which doesn't require them. > > In the context of a CoC, having some escalation procedures for if > people refuse to compromise sharpens the minds of those involved - > they can't just half-heartedly reply to a complaint and carry on as > they were, but have to at least engage with the issue raised. Thinking > about it, the same happens in many civil court cases - nobody would > agree to an "out of court settlement" if there was no court case to be > avoided. > > So insisting on having "teeth", but assuring people that they will > probably never be used, is a justifiable position, not a contradiction. > > Regards, Taking your nuclear weapons analogy a little further, we are now (as a world) very concerned about making sure that the wrong people do not get access to nuclear weapons. Whilst we cannot go back and un-invent the nuclear weapon, we can avoid creating a punitive process which we have to 'play politics' around to try to keep it under control. I don't object to the idea that people who are clearly being unconstructive can be blocked from the project. What I object to is the proposal to make this an opaque 'secret court' where a few 'judges' have the ability to make secret decisions based on secret reports and secret evidence. The community has always had the means to remove people from the process which has, to my knowledge, been invoked in the past a small number of times. Therefore, we already have the 'teeth' to enforce the CoC in borderline cases, but what's being proposed is an inexplicable move from visible and transparent 'teeth' to an opaque and closed process. In case I was getting this all wrong, I made a pull request to remove this secrecy from the process, which was promptly closed: https://github.com/derickr/php-community-health/pull/37 I'd suggest that we stick with the teeth we already have, rather than creating a new set based on an issue which has occurred a couple of times in a decade, and always been adequately resolved. - Matt.