Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84509 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 17869 invoked from network); 10 Mar 2015 16:52:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Mar 2015 16:52:14 -0000 Authentication-Results: pb1.pair.com header.from=ircmaxell@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=ircmaxell@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.51 as permitted sender) X-PHP-List-Original-Sender: ircmaxell@gmail.com X-Host-Fingerprint: 209.85.215.51 mail-la0-f51.google.com Received: from [209.85.215.51] ([209.85.215.51:43950] helo=mail-la0-f51.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F0/46-08808-D312FF45 for ; Tue, 10 Mar 2015 11:52:13 -0500 Received: by labge10 with SMTP id ge10so2634494lab.10 for ; Tue, 10 Mar 2015 09:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=saReTChAGoyhdU5t4aeA0BwKgjhPFPsMjdiDmeyszmc=; b=xL4Me4Vba1EiP7pl/2XFxIyC6iNu4aUmM3/TvHkQIPPrYm61gdhg7P/urw1iCWhuJV 94LJiVAKiaY+H1pl0EzHM5eCTOBM9qN7Rfb5ldbmiCpcoDamt4OQs+iG26aajAQWrVCK QVIhdffcLBfTX/NSdz4zv896utiIKqGu3Q+AE656C+1ILtX+Cz6Nc0snBKsm75BgxOis DpFaf5assJ30m59oNA+9AwZgJohmBlp/a0bS48xEBRaMJXjvMdK1ulbTrjOwtX4Z9qg9 bAgKxVvaPMtNQRWdNFGD867CvHLx5P/QYYeD04ZpNU9e1/zMAkS7n1uDsMQj5dAS8mm8 4BnA== MIME-Version: 1.0 X-Received: by 10.112.67.107 with SMTP id m11mr6475747lbt.43.1426006330014; Tue, 10 Mar 2015 09:52:10 -0700 (PDT) Received: by 10.25.43.9 with HTTP; Tue, 10 Mar 2015 09:52:09 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 Mar 2015 12:52:09 -0400 Message-ID: To: Dan Ackroyd Cc: Patrick ALLAERT , marcio3w@gmail.com, Yasuo Ohgaki , PHP internals Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] Voting choice for language changes (Was: "Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count") From: ircmaxell@gmail.com (Anthony Ferrara) Dan, On Tue, Mar 10, 2015 at 11:45 AM, Dan Ackroyd wrote: > On 10 March 2015 at 15:02, Anthony Ferrara wrote: >> >> Can we please come down to a single RFC, with a single vote yes/no? >> It's easier to understand, easier to manage and has less possibility >> of gaming. > > > While I generally agree, in the case where there is a small detail > that needs to be addresses by a vote, I think having two votes in one > RFC is better than having two almost identical RFCs. > > However the question that is being voted on needs to be setup properly > so that it does not prevent people from being able to vote on both > issues. > > For example the group use RFC > (https://wiki.php.net/rfc/group_use_declarations) has a small detail > of whether there should be a trailing slash in the syntax, which did > not deserve a separate RFC imo. > > Unfortunately, the vote options were: > - Yes - with a trailing "\" > - Yes - without a trailing "\" > - No In this case, a straw-poll ahead of time for "with or without" could have solved that. Or just choosing one. But in more complex situations it doesn't need to be competing RFCs, but a RFC for the main thing, and a RFC to choose which option. This case (with/without "\") isn't what I was referring to. I was talking more about situations like: https://wiki.php.net/rfc/error_handler_callback_parameters_passed_by_reference#vote Specifically where the options have pretty significant difference in potential functionality. https://wiki.php.net/rfc/pecl_http#vote Here, enabled/disabled by default, and the namespace? The namespace is a pretty significant concern. I believe that the RFC should have taken a stance on it. But if it didn't want to, it could split it off into its own proposal. So you'd have RFC#1: add pecl_http to core, and RFC#2: change pecl_http to use the php\ namespace prefix. By splitting it apart it's a lot clearer what's going on, and the impact of the decision can be weighed. If I was doing the proposal though, I would make a single RFC that takes a stance (picks one). Then let the discussion guide the change. If people really feel that another option is better, it will become clear, so the RFC can be updated. That's the point of discussion, no? Anthony