Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:72545 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 28080 invoked from network); 13 Feb 2014 06:35:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Feb 2014 06:35:13 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.107 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.107 smtp107.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.107] ([108.166.43.107:48168] helo=smtp107.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 95/00-27664-0A76CF25 for ; Thu, 13 Feb 2014 01:35:13 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 5594C98124; Thu, 13 Feb 2014 01:35:10 -0500 (EST) X-Virus-Scanned: OK Received: by smtp6.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id F20D098123; Thu, 13 Feb 2014 01:35:09 -0500 (EST) Message-ID: <52FC679D.4@sugarcrm.com> Date: Wed, 12 Feb 2014 22:35:09 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Yasuo Ohgaki , "internals@lists.php.net" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC DISCUSSION] Have voting options to show reason why dislike proposal. From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > Since RFC is technical discussion, there should be good reasons to oppose > proposals and these opinions should be used to improve/create another RFC. In general, there's no burden of proof to not introduce some feature or change. It is the default. PHP has worked for many years before without that feature, however good may it be, so it is proven we can live without it, even if it appears very good (of course, this does not include high-exposure security issues, etc. but we're talking about regular stuff I suppose). The burden of proof is on the proposer to convince people that with that feature it would be much better than without it. Sometimes it is obvious (unanimous approval votes aren't unheard of), sometimes it is not that obvious. Sometimes people just don't realize it is important, sometimes they disagree on the importance, sometimes it's just not the right time for it. In this case, the burden is on the proposer to solicit feedback and figure out why people are not convinced and what could be done, if anything, to convince them. So yes, it would be very good if people who disagree with the RFC would voice their concerns, when they are different from ones already voiced on the list ("me too" is not very useful). Especially if disagreement is of constructive nature and can be resolved with some modification. But I don't think there's a real duty for people to explain each of their "no" vote if they just don't feel like spending time arguing. Not everybody would do it, and nobody should be forced to do it (I'm not speaking about myself here, if I disagree with something I usually make it known ;). Thus I think there's no need to add any special things - we have the list, and if the discussion continues whithin the vote, the vote can always be extended or even restarted. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227