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 :
> >
> > 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-12 Thread Dan Ackroyd
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

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-10 Thread Marcio Almada
Hi,

2015-03-10 12:45 GMT-03:00 Dan Ackroyd :

> 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
>
> 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


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 :

> 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?
>
>
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
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
 wrote:
> Hello,
>
> Le ven. 6 mars 2015 à 00:44, Marcio Almada  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 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

-- 
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 :
> 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



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

2015-03-10 Thread Patrick ALLAERT
Hello,

Le ven. 6 mars 2015 à 00:44, Marcio Almada  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