2015-03-10 13:52 GMT-03:00 Anthony Ferrara <ircmax...@gmail.com>: > Dan, > > On Tue, Mar 10, 2015 at 11:45 AM, Dan Ackroyd <dan...@basereality.com> > wrote: > > On 10 March 2015 at 15:02, Anthony Ferrara <ircmax...@gmail.com> 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? > > Yes, that is the point of discussion. But, unfortunately, a lot of RFCs only start to get discussed when the voting is open. I don't know why this happens, but it's a pattern I've been observing for some time. In general, I agree with you, we should make some effort to eliminate voting options during discussion phase, or at least reduce the options to a minimum amount.
> Anthony >
