Re: [PHP-DEV] Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)
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 This meant it was impossible for people who wanted to vote no to the general idea, to say what was their preferred choice of syntax. The questions and voting choices should have been: Should Grouped Use Declarations be added to PHP 7 - Yes - No If added, should the syntax be with trailing \ or without. - With a trailing \ - Without a trailing \ This would have allowed all voters to express their intent for both parts of the question, without being forced to vote 'yes' if they want a say in the exact syntax used. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)
On Tue, 10 Mar 2015, Patrick ALLAERT wrote: 2015-03-10 16:02 GMT+01:00 Anthony Ferrara ircmax...@gmail.com: 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. That is much more stricter than my thoughts but I can't agree more with you on all the points you mentioned. You even presented cases I had in mind, thanks for the verbosity :) +1 We should probably add this to https://wiki.php.net/rfc/voting which should probably RFC'ed... I think you just volunteerd ;-) cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)
Patrick, My viewpoint is that options in an RFC are dangerous. I would much rather have a single RFC, with a single vote (yes/no). I think we should be discouraging the options as much as possible. The reason is simple: an RFC should be an encapsulated idea, not a menu of options. The author should take a stance. If there are details that the author can't decide on, then either take a straw poll in the mailing list, or create a separate RFC for that option. The problem with options is that it makes the vote much more confusing. With 3 options, you have 3 different proposals. Some recent votes have had upwards of 12 different proposals built in to a single RFC (2 options + 3 options + 2 options). It's enough to ask someone to read and understand one proposal completely without having them have to comprehend all the possible permutations of voting outcomes. It also encourages weird voting patterns. Take your example of No/Yes, A/B/C. In that case, you have 4 permutations as you pointed out. But what's deeper, is how should someone vote if they are opposed to B? I mean opposed, not just preferring a different one? The tendency would likely be to watch the vote and if it looks like B will pass, vote no on the entire proposal. 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. Anthony On Tue, Mar 10, 2015 at 10:39 AM, Patrick ALLAERT patrickalla...@php.net wrote: Hello, Le ven. 6 mars 2015 à 00:44, Marcio Almada marcio.w...@gmail.com a écrit : You are right about this. I'll setup a yes/no vote + a vote to decide between E_WARNING (for consistency), E_DEPRECATED or E_STRICT. For me this is just a detail but maybe it's very important to others, so better to let each voter decide upon it. In case of language changes, shouldn't the 2/3 of majority be required at any levels? In situations like: Main feature: No/Yes Option: A, B or C My gut feeling is that it would be better to rally a 2/3 majority of people behind one of: No / Yes (A) / Yes (B) / Yes (C) in order to not dilute the importance of language changes. It would prevent accepting an important change where a lot of people agrees on a general idea but have strong opinions/arguments on implementation/details. Cheers, Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)
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
Re: [PHP-DEV] Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)
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? Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)
2015-03-10 16:02 GMT+01:00 Anthony Ferrara ircmax...@gmail.com: Patrick, My viewpoint is that options in an RFC are dangerous. I would much rather have a single RFC, with a single vote (yes/no). I think we should be discouraging the options as much as possible. The reason is simple: an RFC should be an encapsulated idea, not a menu of options. The author should take a stance. If there are details that the author can't decide on, then either take a straw poll in the mailing list, or create a separate RFC for that option. The problem with options is that it makes the vote much more confusing. With 3 options, you have 3 different proposals. Some recent votes have had upwards of 12 different proposals built in to a single RFC (2 options + 3 options + 2 options). It's enough to ask someone to read and understand one proposal completely without having them have to comprehend all the possible permutations of voting outcomes. It also encourages weird voting patterns. Take your example of No/Yes, A/B/C. In that case, you have 4 permutations as you pointed out. But what's deeper, is how should someone vote if they are opposed to B? I mean opposed, not just preferring a different one? The tendency would likely be to watch the vote and if it looks like B will pass, vote no on the entire proposal. 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. Anthony That is much more stricter than my thoughts but I can't agree more with you on all the points you mentioned. You even presented cases I had in mind, thanks for the verbosity :) We should probably add this to https://wiki.php.net/rfc/voting which should probably RFC'ed... Thanks! Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)
Hi, 2015-03-10 12:45 GMT-03:00 Dan Ackroyd dan...@basereality.com: 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 This meant it was impossible for people who wanted to vote no to the general idea, to say what was their preferred choice of syntax. The questions and voting choices should have been: Should Grouped Use Declarations be added to PHP 7 - Yes - No If added, should the syntax be with trailing \ or without. - With a trailing \ - Without a trailing \ This would have allowed all voters to express their intent for both parts of the question, without being forced to vote 'yes' if they want a say in the exact syntax used. cheers Dan Ack That's so true. The Group Use... was my first RFC and I have to admit this voting setup was poor decision taking on my part, sorry. Later some people even confessed that they didn't vote yes because they haven't noticed it was necessary when in reality they just couldn't realize they should sum the yes votes to know if the RFC was passing or not. I'll avoid to setup a vote like this again and will always prefer the multiple questions approach in situations where options are inevitable. Thanks, Márcio
