Re: [PHP-DEV] Voting choice for language changes (Was: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count)

2015-03-12 Thread Dan Ackroyd
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)

2015-03-12 Thread Derick Rethans
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)

2015-03-10 Thread Anthony Ferrara
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 Thread Marcio Almada
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)

2015-03-10 Thread Anthony Ferrara
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 Thread Patrick ALLAERT
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)

2015-03-10 Thread Marcio Almada
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