Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:56260 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 83688 invoked from network); 10 Nov 2011 22:32:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Nov 2011 22:32:47 -0000 Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.213.42 cause and error) X-PHP-List-Original-Sender: rasmus@lerdorf.com X-Host-Fingerprint: 209.85.213.42 mail-yw0-f42.google.com Received: from [209.85.213.42] ([209.85.213.42:41437] helo=mail-yw0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C1/00-17932-E015CBE4 for ; Thu, 10 Nov 2011 17:32:46 -0500 Received: by ywm19 with SMTP id 19so2029155ywm.29 for ; Thu, 10 Nov 2011 14:32:43 -0800 (PST) Received: by 10.68.35.129 with SMTP id h1mr18363732pbj.92.1320964363224; Thu, 10 Nov 2011 14:32:43 -0800 (PST) Received: from [192.168.200.5] (c-50-131-44-225.hsd1.ca.comcast.net. [50.131.44.225]) by mx.google.com with ESMTPS id p10sm24767396pbd.15.2011.11.10.14.32.41 (version=SSLv3 cipher=OTHER); Thu, 10 Nov 2011 14:32:42 -0800 (PST) Message-ID: <4EBC5109.8070907@lerdorf.com> Date: Thu, 10 Nov 2011 14:32:41 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Pierre Joye CC: PHP Internals References: <4EBADCE4.9030702@sugarcrm.com> <4EBAF5D8.40608@sugarcrm.com> <4EBB5847.50400@lerdorf.com> <4EBBFE8B.40308@lerdorf.com> <4EBC1564.8090600@lerdorf.com> <4EBC2E68.7010403@lerdorf.com> In-Reply-To: X-Enigmail-Version: 1.4a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] who can vote From: rasmus@lerdorf.com (Rasmus Lerdorf) On 11/10/2011 01:17 PM, Pierre Joye wrote: > If that's not the case, and after a 2nd thought, it is actually not > the case, then we can just discard this whole thread and go back to > code and proposals. I only find very disturbing to have to explain and > argue so many times about that only because we have a edge case in a > proposal (which is perfectly valid, that happens, show must go on). The problem with some RFCs is that it is not clear what people are voting on. In some cases people are voting for or against a proposal based solely on the concept while other people are looking at the nitty gritty details of the implementation and voting against it due to implementation problems. Then there are procedural problems like the RFC changing during the voting process. As long as it is completely obvious what is being voted on and the process is followed, the voting RFC rules are fine. It would be nice though if we could iterate in order to get 2/3 approval on most proposals. It is these 50/50 ones that are problematic and often boil down to half the people voting, "We want this feature!" and the other half voting, "Yes, but this implementation, as proposed, is half-baked." In cases like this where we end up in a 50/50 standoff instead of pushing thought with 50+1 I would much rather see each of the valid criticisms added to the RFC with an explanation of what the problem is and what is or isn't being done to address it and open the voting for another week to give the former no (or yes) voters a chance to be better informed and change or add their votes. -Rasmus