Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:91168 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 97206 invoked from network); 9 Feb 2016 15:51:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Feb 2016 15:51:13 -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:25207] helo=sender163-mail.zoho.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 91/CA-39202-0FA0AB65 for ; Tue, 09 Feb 2016 10:51:13 -0500 Received: from [192.168.0.5] (5ec1ae50.skybroadband.com [94.193.174.80]) by mx.zohomail.com with SMTPS id 1455033068877312.46188441823836; Tue, 9 Feb 2016 07:51:08 -0800 (PST) To: internals@lists.php.net References: <56B9F00B.5020305@mprelu.de> <56B9F865.5000005@gmail.com> <56BA01B5.3050303@mprelu.de> <56BA04BA.8020306@gmail.com> Message-ID: <56BA0AEA.9090906@mprelu.de> Date: Tue, 9 Feb 2016 15:51:06 +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: <56BA04BA.8020306@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 Rowan, On 09/02/16 15:24, Rowan Collins wrote: > That said, I am not convinced either > a) that the current process has any guarantee of transparency - who > exactly has the right to block people from the list, or revoke other > karma? what transparent process are they obliged to follow when doing so? Here, we agree. Nowhere in the documents does it limit the extent to which evidence can be truncated or redacted in the name of 'privacy'. Nowhere in the documents does it guarantee the accused a right to face the evidence which has been brought against him/her. Nowhere in the documents does it specify a standard of evidence, or explain legitimate defences against accusations. On 09/02/16 15:24, Rowan Collins wrote: > or b) that the current draft entail a "secret court" - the wording you > filed a PR to remove talks only about anonymity of witnesses (which, > admittedly, includes "accusers"), and makes no mention of "secret > decisions based on secret reports and secret evidence" These speculations are from the prior discussion of the RFC when it was proposed by Anthony. The Contributor Covenant (which is the basis of the Code of Conduct document) is designed to protect the identity of the accuser, rather than the right of the accused to face the evidence against him/her. I see these priorities as backwards. The current wording of the 'Code of Conduct' contains the following text: "Maintainers are obligated to maintain confidentiality with regard to both the reporter of an incident, and the accused, and expect all parties to assist in ensuring this." In addition, the 'Mediation' document contains the following: "Reasonable efforts should be taken to ensure the privacy of the reporting party. The only two exceptions are if the incident was public or if the reporting party agrees to be identified." In common law (probably the most functional legal system on the planet), a core right of the accused is to 'face his accuser', i.e. to see exactly what he is being accused of and by whom. I would be very reluctant to support any process which does not respect this *core* legal right. Without the right to face the accuser, the accusation, or a guarantee that all supporting AND contradictory evidence and testimony will be published, this is a 'secret court' proposal. On 09/02/16 15:24, Rowan Collins wrote: > Again, this is jumping ahead to the details of the implementation, > which Derrick has said will be discussed at a later date. > > The principle at discussion right now, is that on the face of it, > there should be some definition of enforcement mechanism. If you > consider the status quo to include such an enforcement mechanism, and > do not wish to remove it, then you agree with that general principle. With respect, I don't think that disagreeing that there is any need for a new enforcement process is 'agreeing with' the new RFC. - Matt.