Hi everyone,
The vote on the OpenSSL AEAD RFC[1] has made me question our current RFC
process again. Under the Voting RFC[2], "Language changes" (in practice,
changes to syntax and semantics) require at least a 2/3 majority to pass
when they come to a vote, whereas changes that don't fall under that
category require a mere plurality of more Yes votes than No votes, aka
"50%+1".
The stated justification for the 2/3 requirement is that such changes
are more permanent and shouldn't be arbitrary. However, there's no
justification given for why other RFCs shouldn't receive the same
level of scrutiny.
Consider that the language, in practice, is not simply the syntax and
semantics specified by the language specification and implemented by the
Zend Engine or HHVM. PHP's bundled extensions are also an important part
of PHP which define the language: an implementation of PHP which lacked
them would not be very useful for running real PHP applications, and it
is only with considerable difficulty that you could write PHP code
without them. In fact, certain key primitive operations on PHP's
built-in datatypes are only exposed through functions in ext/standard!
And yet, RFC votes on changes to the extensions are held to a lesser
standard than changes to the syntax.
Another thing to consider is the types of changes that RFCs propose.
These are usually used for changes that should not simply get in through
consensus around a pull request. This can range from simply adding new
functions, to making backwards-incompatible changes. These are not
decisions to be taken lightly.
Finally, I think that a proposal that is good enough will have no
trouble achieving a 2/3 majority anyway. In practice, many RFCs pass by
unanimous vote!
So, would there be support for raising the passing threshold for
non-"language changes" to 2/3? At the very least, I think we should have
this for backwards-incompatible changes. If there's enough support, I'll
write an RFC, though I'll have to figure out how exactly to change the
rules. (Can the voting RFC be amended by another RFC? The RFC process
isn't a good fit for procedural things like this.)
Thanks!
[1] https://wiki.php.net/rfc/openssl_aead
[2] https://wiki.php.net/rfc/voting
Andrea Faulds
https://ajf.me/
As someone who has never participated with intervals before and only just recently subscribed to the list, I would like to see a minimum percentage of voting members participating in a vote for something to pass. In my interpretation of the current rules, a measure could pass with only 3 votes cast (2 for / 1 against). In fact, there was a recent proposal that passed with only 11 votes cast. If that few of voting members are participating, maybe the proposal wasn't clear enough (or maybe it's just not needed at all)? Sure you can argue that they had ample time to discuss, but I would say perhaps they just saw no value in it. If a proposal isn't offering enough value for the greater community, maybe it doesn't belong in core and should be either a pecl extension or userland code?
Joe Constant
Hi everyone,
The vote on the OpenSSL AEAD RFC[1] has made me question our current RFC process again. Under the Voting RFC[2], "Language changes" (in practice, changes to syntax and semantics) require at least a 2/3 majority to pass when they come to a vote, whereas changes that don't fall under that category require a mere plurality of more Yes votes than No votes, aka "50%+1".
The stated justification for the 2/3 requirement is that such changes are more permanent and shouldn't be arbitrary. However, there's no justification given for why other RFCs shouldn't receive the same level of scrutiny.
Consider that the language, in practice, is not simply the syntax and semantics specified by the language specification and implemented by the Zend Engine or HHVM. PHP's bundled extensions are also an important part of PHP which define the language: an implementation of PHP which lacked them would not be very useful for running real PHP applications, and it is only with considerable difficulty that you could write PHP code without them. In fact, certain key primitive operations on PHP's built-in datatypes are only exposed through functions in ext/standard! And yet, RFC votes on changes to the extensions are held to a lesser standard than changes to the syntax.
Another thing to consider is the types of changes that RFCs propose. These are usually used for changes that should not simply get in through consensus around a pull request. This can range from simply adding new functions, to making backwards-incompatible changes. These are not decisions to be taken lightly.
Finally, I think that a proposal that is good enough will have no trouble achieving a 2/3 majority anyway. In practice, many RFCs pass by unanimous vote!
So, would there be support for raising the passing threshold for non-"language changes" to 2/3? At the very least, I think we should have this for backwards-incompatible changes. If there's enough support, I'll write an RFC, though I'll have to figure out how exactly to change the rules. (Can the voting RFC be amended by another RFC? The RFC process isn't a good fit for procedural things like this.)
Thanks!
[1] https://wiki.php.net/rfc/openssl_aead
[2] https://wiki.php.net/rfc/voting
Andrea Faulds
https://ajf.me/
As someone who has never participated with intervals before and only just
recently subscribed to the list, I would like to see a minimum percentage
of voting members participating in a vote for something to pass. In my
interpretation of the current rules, a measure could pass with only 3 votes
cast (2 for / 1 against). In fact, there was a recent proposal that passed
with only 11 votes cast. If that few of voting members are participating,
maybe the proposal wasn't clear enough (or maybe it's just not needed at
all)? Sure you can argue that they had ample time to discuss, but I would
say perhaps they just saw no value in it. If a proposal isn't offering
enough value for the greater community, maybe it doesn't belong in core and
should be either a pecl extension or userland code?
I disagree with this. The fact that not many people voted doesn't mean that
the feature is not important. Some RFC are very technical and about
specific topics that not many voters is interested in. However it can be
important for some users and shouldn't be rejected just because there are
not enough votes even if the majority is in favour. It's often a specific
feature for extension so moving everything to PECL is not really an option.
P.S. Please don't top post... ;)
Cheers
Jakub
P.S. Please don't top post... ;)
I'm not trying to thread hijack. Just trying to add to the discussion. The ops post was in regards to RFCs passing to easily. My contention with the low voter turnout is in line (or at least intended to be in line) with that.
It's often a specific feature for extension so moving everything to PECL is not really an option.
My argument is that if it affects core, a certain percentage of voting members (people that have taken on the responsibility of directing the future of core) should be required to vote. I understand that they may not be interested, but if the voter turnout is really that low, the proponents should be doing more to drum up interest rather than simply allowing an RFC to pass.
Joe Constant
As someone who has never participated with intervals before and only just recently subscribed to the list, I would like to see a minimum percentage of voting members participating in a vote for something to pass. In my interpretation of the current rules, a measure could pass with only 3 votes cast (2 for / 1 against). In fact, there was a recent proposal that passed with only 11 votes cast. If that few of voting members are participating, maybe the proposal wasn't clear enough (or maybe it's just not needed at all)? Sure you can argue that they had ample time to discuss, but I would say perhaps they just saw no value in it. If a proposal isn't offering enough value for the greater community, maybe it doesn't belong in core and should be either a pecl extension or userland code?
I disagree with this. The fact that not many people voted doesn't mean that the feature is not important. Some RFC are very technical and about specific topics that not many voters is interested in. However it can be important for some users and shouldn't be rejected just because there are not enough votes even if the majority is in favour. It's often a specific feature for extension so moving everything to PECL is not really an option.
P.S. Please don't top post... ;)
Cheers
Jakub
P.S. Please don't top post... ;)
I'm not trying to thread hijack. Just trying to add to the discussion.
The ops post was in regards to RFCs passing to easily. My contention with
the low voter turnout is in line (or at least intended to be in line) with
that.
No worries. It was just a friendly reminder that top posting makes a
discussion hard to follow. ;) I didn't try to suggest that you are trying
to hijack the thread. Btw. you still top post (the previous email was
below...) :) try to reply into the message or below, then it's cool ;)
It's often a specific feature for extension so moving everything to
PECL is not really an option.
My argument is that if it affects core, a certain percentage of voting
members (people that have taken on the responsibility of directing the
future of core) should be required to vote. I understand that they may not
be interested, but if the voter turnout is really that low, the proponents
should be doing more to drum up interest rather than simply allowing an RFC
to pass.
I think that the main problem is that many of our core extensions are quite
neglected. There is a much bigger interest in a fancy core engine
(language) features than in fixing bugs or adding small features to the
core extension. I don't think there should be any limit on number of votes
as it would make it hard to get small features in. Of course there is no
point in doing RFC if there is no objection but if there was a single
objection to a small feature, then it would be almost impossible to get it
in.
Cheers
Jakub
Hi everyone,
The vote on the OpenSSL AEAD RFC[1] has made me question our current RFC
process again. Under the Voting RFC[2], "Language changes" (in practice,
changes to syntax and semantics) require at least a 2/3 majority to pass
when they come to a vote, whereas changes that don't fall under that
category require a mere plurality of more Yes votes than No votes, aka
"50%+1".The stated justification for the 2/3 requirement is that such changes are
more permanent and shouldn't be arbitrary. However, there's no justification
given for why other RFCs shouldn't receive the same level of scrutiny.Consider that the language, in practice, is not simply the syntax and
semantics specified by the language specification and implemented by the
Zend Engine or HHVM. PHP's bundled extensions are also an important part of
PHP which define the language: an implementation of PHP which lacked them
would not be very useful for running real PHP applications, and it is only
with considerable difficulty that you could write PHP code without them. In
fact, certain key primitive operations on PHP's built-in datatypes are only
exposed through functions in ext/standard! And yet, RFC votes on changes to
the extensions are held to a lesser standard than changes to the syntax.Another thing to consider is the types of changes that RFCs propose. These
are usually used for changes that should not simply get in through consensus
around a pull request. This can range from simply adding new functions, to
making backwards-incompatible changes. These are not decisions to be taken
lightly.Finally, I think that a proposal that is good enough will have no trouble
achieving a 2/3 majority anyway. In practice, many RFCs pass by unanimous
vote!So, would there be support for raising the passing threshold for
non-"language changes" to 2/3? At the very least, I think we should have
this for backwards-incompatible changes. If there's enough support, I'll
write an RFC, though I'll have to figure out how exactly to change the
rules. (Can the voting RFC be amended by another RFC? The RFC process isn't
a good fit for procedural things like this.)Thanks!
[1] https://wiki.php.net/rfc/openssl_aead
[2] https://wiki.php.net/rfc/votingAndrea Faulds
https://ajf.me/--
I've been wanting to propose bumping the required % to always be 2/3
for quite some time and just didn't have the energy or time to conduct
a discussion about it. I fully support this idea. We are at a stage in
PHP's lifecycle where I think we should be more united on changes and
additions or they shouldn't make it it.
Hi everyone,
The vote on the OpenSSL AEAD RFC[1] has made me question our current RFC
process again. Under the Voting RFC[2], "Language changes" (in practice,
changes to syntax and semantics) require at least a 2/3 majority to pass
when they come to a vote, whereas changes that don't fall under that
category require a mere plurality of more Yes votes than No votes, aka
"50%+1".
FYI the OpenSSL AEAD RFC passed 2/3 majority so not sure why it made you
question our RFC process... :)
Hi Jakub,
Jakub Zelenka wrote:
Hi everyone,
The vote on the OpenSSL AEAD RFC[1] has made me question our current RFC
process again. Under the Voting RFC[2], "Language changes" (in practice,
changes to syntax and semantics) require at least a 2/3 majority to pass
when they come to a vote, whereas changes that don't fall under that
category require a mere plurality of more Yes votes than No votes, aka
"50%+1".FYI the OpenSSL AEAD RFC passed 2/3 majority so not sure why it made you
question our RFC process... :)
I went and checked again, and it didn't pass by 2/3. It got 7 votes in
favour and 4 against. To have passed by 2/3, the number of Yes votes
would need to be at least double the number of No votes, but the vote
totals didn't meet that. 7:4 is 63.6%, less than 66.6%.
--
Andrea Faulds
https://ajf.me/
Hi Andrea,
Hi Jakub,
Jakub Zelenka wrote:
Hi everyone,
The vote on the OpenSSL AEAD RFC[1] has made me question our current RFC
process again. Under the Voting RFC[2], "Language changes" (in practice,
changes to syntax and semantics) require at least a 2/3 majority to pass
when they come to a vote, whereas changes that don't fall under that
category require a mere plurality of more Yes votes than No votes, aka
"50%+1".FYI the OpenSSL AEAD RFC passed 2/3 majority so not sure why it made you
question our RFC process... :)I went and checked again, and it didn't pass by 2/3. It got 7 votes in
favour and 4 against. To have passed by 2/3, the number of Yes votes would
need to be at least double the number of No votes, but the vote totals
didn't meet that. 7:4 is 63.6%, less than 66.6%.
Ah you are right. Was thinking that 60% will do for some reason... :) My
fault, sorry. ;)
It means that I have to be glad that we have 50%+1 in that case. :) But
seriously I think that there wasn't a need for a super majority. It doesn't
have any critical consequences and at least the users will get the features
that they wanted. It would be quite hard to keep the ext updated if we had
to have a super majority for everything IMHO... On the other side you have
got a point. It would probably result in better quality if we required it.
But I don't think we have got so many core ext developers that we can
afford that. It could result in less effort to get anything in which is
certainly not good for core extensions. That's basically the difference
that I see between the engine and core extension development. The features
are much more important for some extensions so we should be less strict
IMHO.
Hi everyone,
The vote on the OpenSSL AEAD RFC[1] has made me question our current RFC
process again. Under the Voting RFC[2], "Language changes" (in practice,
changes to syntax and semantics) require at least a 2/3 majority to pass
when they come to a vote, whereas changes that don't fall under that
category require a mere plurality of more Yes votes than No votes, aka
"50%+1".The stated justification for the 2/3 requirement is that such changes are
more permanent and shouldn't be arbitrary. However, there's no
justification given for why other RFCs shouldn't receive the same level
of scrutiny.Consider that the language, in practice, is not simply the syntax and
semantics specified by the language specification and implemented by the
Zend Engine or HHVM. PHP's bundled extensions are also an important part of
PHP which define the language: an implementation of PHP which lacked them
would not be very useful for running real PHP applications, and it is only
with considerable difficulty that you could write PHP code without them. In
fact, certain key primitive operations on PHP's built-in datatypes are only
exposed through functions in ext/standard! And yet, RFC votes on changes to
the extensions are held to a lesser standard than changes to the syntax.Another thing to consider is the types of changes that RFCs propose. These
are usually used for changes that should not simply get in through
consensus around a pull request. This can range from simply adding new
functions, to making backwards-incompatible changes. These are not
decisions to be taken lightly.Finally, I think that a proposal that is good enough will have no trouble
achieving a 2/3 majority anyway. In practice, many RFCs pass by unanimous
vote!So, would there be support for raising the passing threshold for
non-"language changes" to 2/3? At the very least, I think we should have
this for backwards-incompatible changes. If there's enough support, I'll
write an RFC, though I'll have to figure out how exactly to change the
rules. (Can the voting RFC be amended by another RFC? The RFC process isn't
a good fit for procedural things like this.)Thanks!
I'm definitely in favor of requiring a 2/3 majority in all cases. An RFC
that passes with 51:50 votes is clearly not an RFC that a consensus exists
on. On the contrary, it indicates a very controversial change which
requires further deliberation.
In the end, this change will not have significant impact on how many RFCs
we accept. The last time I looked into this, the vast majority of RFCs that
passed at all, also passed with 2/3 majority. This will only filter out a
few controversial cases.
Furthermore requiring a consistent quota for all RFCs will avoid the
inevitable bickering that seems to spring up with many "major" RFCs, about
whether or not a 2/3 vote is required in a particular instance. For RFCs
that are significant, but not clear language changes (like the PHP 7 naming
RFC, or the phpng RFC, or the int size RFC), there's always a dozen or two
mails in the discussion devoted to this most important of questions.
Thanks,
Nikita
Hi Nikita,
Nikita Popov wrote:
I'm definitely in favor of requiring a 2/3 majority in all cases. An RFC
that passes with 51:50 votes is clearly not an RFC that a consensus exists
on. On the contrary, it indicates a very controversial change which
requires further deliberation.
This is a good point. If something can only pass with the 50%+1 rule,
that's not a point in its favour.
Furthermore requiring a consistent quota for all RFCs will avoid the
inevitable bickering that seems to spring up with many "major" RFCs, about
whether or not a 2/3 vote is required in a particular instance. For RFCs
that are significant, but not clear language changes (like the PHP 7 naming
RFC, or the phpng RFC, or the int size RFC), there's always a dozen or two
mails in the discussion devoted to this most important of questions.
This does make me wonder if we might need some language to allow
exceptions to the rule. In the case of the PHP 6/7 vote, for example, it
had to be 50%+1 to avoid giving either side an unfair advantage. But
that wasn't really a normal RFC, anyway. An RFC contains a proposal for
a specific change and a vote is held on whether to accept it or not. The
6/7 RFC was a vote between two opposing proposals presented in the same
RFC, with no option to vote against. It was more of a referendum than
anything else. I'm not sure how to handle cases like that.
Thanks for your reply.
--
Andrea Faulds
https://ajf.me/
Hi Andrea,
Nikita Popov wrote:
I'm definitely in favor of requiring a 2/3 majority in all cases. An RFC
that passes with 51:50 votes is clearly not an RFC that a consensus exists
on. On the contrary, it indicates a very controversial change which
requires further deliberation.This is a good point. If something can only pass with the 50%+1 rule, that's
not a point in its favour.
I agree it's good to have 2/3 majority in all cases in general.
It means people who vote against a proposal have twice worth of vote
than supporters. It's ok to have twice value if the reason why he/she
opposed is solid, reasonable and disclosed. Disclosure is mandatory
for RFC improvement, what's missing - description and/or feature,
what's not preferred, what's the better way to do it, etc.
It's ok to reject a RFC by "I don't think it is not needed" for simple
additions like array_find_recursive() - it's imaginably RFC. However,
it is not ok for some change/addition like mine
https://wiki.php.net/rfc/precise_session_management
This RFC includes mandatory session management behaviors and not
disclosing why someone objects it, is not nice thing to see. Opposing
votes for "Precise Session Management" would mean most likely, "My
description was not good enough to be understood by everyone" or "Some
implementation is not preferred" or even "There are better ways to do
this".
2/3 majority sounds good, if people who against a proposal explicitly
disclose the reason why. Reasons for opposition are required for
RFC/implementation improvements if it is needed.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
It's ok to reject a RFC by "I don't think it is not needed" for simple
additions like array_find_recursive() - it's imaginably RFC. However,
it is not ok for some change/addition like mine
https://wiki.php.net/rfc/precise_session_management
This RFC includes mandatory session management behaviors and not
disclosing why someone objects it, is not nice thing to see. Opposing
votes for "Precise Session Management" would mean most likely, "My
description was not good enough to be understood by everyone" or "Some
implementation is not preferred" or even "There are better ways to do
this".
Turning that around ... Are there better ways of doing this? In
situations where security is not an issue, such as private networks,
many of the elements of 'making PHP more secure' simple add work without
any real gain, but the fact that some interactions with the browser are
now well out of date should prompt a discussion to fix the whole
process? We have improved international working, including handling
timezones, but there is still no mechanism to establish an anonymous
users local timezone. It's only a small hole, but twice a year in a
substantial part of the world the local time has holes and while running
the server UTC allows the sessions to be consistent, the actual client
time may be an hour adrift.
2/3 majority sounds good, if people who against a proposal explicitly
disclose the reason why. Reasons for opposition are required for
RFC/implementation improvements if it is needed.
As Zeev has already demonstrated, the bulk of RFC's do not even really
need a vote, and the minority objections perhaps simply need better
understanding as you say. The problem that will remain is pushing
stronger typing and naming of everything through the whole
infrastructure? When some of us don't have a need for it while others
think that it should be a default security issue? There is now a two
stream model created because there was essentially no consensus on the
issue and while some have 'backed down', it does not mean that moving
further down that road is already a dun deal? I would prefer that my IDE
dealt with many of the problems that others think should be 'compiled
in' but both roadmaps are equally valid?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Morning internalz,
RFC's aren't a good fit for changing procedure, but it's all we have.
This should be the first non-language change RFC that requires a 2/3
majority, I think.
+1 from me anyway, good points have already been made.
Cheers
Joe
Hi Andrea,
Nikita Popov wrote:
I'm definitely in favor of requiring a 2/3 majority in all cases. An RFC
that passes with 51:50 votes is clearly not an RFC that a consensus
exists
on. On the contrary, it indicates a very controversial change which
requires further deliberation.This is a good point. If something can only pass with the 50%+1 rule,
that's
not a point in its favour.I agree it's good to have 2/3 majority in all cases in general.
It means people who vote against a proposal have twice worth of vote
than supporters. It's ok to have twice value if the reason why he/she
opposed is solid, reasonable and disclosed. Disclosure is mandatory
for RFC improvement, what's missing - description and/or feature,
what's not preferred, what's the better way to do it, etc.It's ok to reject a RFC by "I don't think it is not needed" for simple
additions like array_find_recursive() - it's imaginably RFC. However,
it is not ok for some change/addition like mine
https://wiki.php.net/rfc/precise_session_management
This RFC includes mandatory session management behaviors and not
disclosing why someone objects it, is not nice thing to see. Opposing
votes for "Precise Session Management" would mean most likely, "My
description was not good enough to be understood by everyone" or "Some
implementation is not preferred" or even "There are better ways to do
this".2/3 majority sounds good, if people who against a proposal explicitly
disclose the reason why. Reasons for opposition are required for
RFC/implementation improvements if it is needed.Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net