Afternoon internals,
This has been discussed before in various RFC threads, there does seem to
be some consensus that 50%+1 votes could be harmful.
To what degree, I am not sure.
I raise for discussion the topic of abolishing 50%+1 votes, and requiring
all changes regardless of their nature to pass by a super majority of
2/3+1.
Please read the (brief) RFC and raise objections here.
There will be a one week discussion period for this RFC.
Cheers
Joe
Afternoon internals,
This has been discussed before in various RFC threads, there does seem to
be some consensus that 50%+1 votes could be harmful.To what degree, I am not sure.
I raise for discussion the topic of abolishing 50%+1 votes, and requiring
all changes regardless of their nature to pass by a super majority of
2/3+1.
For a language tool as critical as PHP it would be better to consider
a larger sample size such as 75%+1. However the merit is the issue and
not the mass vote. IMHO.
Dennis Clarke
Afternoon internals,
https://wiki.php.net/rfc/abolish-narrow-margins
Cheers
Joe
On Thu, Nov 17, 2016 at 5:33 PM, Dennis Clarke dclarke@blastwave.org
wrote:
Afternoon internals,
This has been discussed before in various RFC threads, there does seem to
be some consensus that 50%+1 votes could be harmful.To what degree, I am not sure.
I raise for discussion the topic of abolishing 50%+1 votes, and requiring
all changes regardless of their nature to pass by a super majority of
2/3+1.For a language tool as critical as PHP it would be better to consider
a larger sample size such as 75%+1. However the merit is the issue and
not the mass vote. IMHO.Dennis Clarke
Afternoon internals,
https://wiki.php.net/rfc/abolish-narrow-margins
Cheers
Joe
Afternoon internals,
This has been discussed before in various RFC threads, there does seem to
be some consensus that 50%+1 votes could be harmful.To what degree, I am not sure.
I raise for discussion the topic of abolishing 50%+1 votes, and requiring
all changes regardless of their nature to pass by a super majority of
2/3+1.Please read the (brief) RFC and raise objections here.
There will be a one week discussion period for this RFC.
Cheers
Joe
Hi Joe,
Requiring 2/3 majority is reasonable.
I'll vote yes for this if people who are not in favor disclose the
reason why. Just voting "no" for a RFC is not constructive. Improving
a RFC is difficult without reason why it is not preferred. Decision
could be based on wrong assumption and/or misunderstanding sometimes.
Could we have comment plugin for this? It does not have be to a
comment plugin, if there is better plugin for the purpose.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Requiring 2/3 majority is reasonable.
I'll vote yes for this if people who are not in favor disclose the
reason why. Just voting "no" for a RFC is not constructive. Improving
a RFC is difficult without reason why it is not preferred. Decision
could be based on wrong assumption and/or misunderstanding sometimes.Could we have comment plugin for this? It does not have be to a
comment plugin, if there is better plugin for the purpose.
We may consider to customize the doodle plugin[1]. IIRC, it is
alread customized and the original is unmaintained, so there
won't be update issues.
[1]
https://github.com/php/web-wiki/tree/master/dokuwiki/lib/plugins/doodle
--
Christoph M. Becker
Afternoon Yasuo,
Maybe, it is our fault - the person who created the RFC.
In an ideal world, during discussion you should collect legitimate
unresolved objections, and have those as "no" options on the vote.
If when it came to vote time, the options were:
Yes
No because X
No because Y
No because Z
No
I think most people would be happy to provide a reason, if you have it
listed.
It should be listed, because it should have been brought up during
discussion.
Obviously we don't live in an ideal world, and you may get lots of no votes
still that don't provide a reason.
But it doesn't need to be ideal to give us some clue of where to take the
RFC next.
Many people don't like the idea of requiring a reason, but I'm sure the
same people would provide one if it were listed as a voting option. What
they don't want is to have to constantly defend their decision after it's
been made, which is in some sense reasonable.
Cheers
Joe
Hi Joe,
On Fri, Nov 18, 2016 at 2:53 AM, Joe Watkins pthreads@pthreads.org
wrote:Requiring 2/3 majority is reasonable.
I'll vote yes for this if people who are not in favor disclose the
reason why. Just voting "no" for a RFC is not constructive. Improving
a RFC is difficult without reason why it is not preferred. Decision
could be based on wrong assumption and/or misunderstanding sometimes.Could we have comment plugin for this? It does not have be to a
comment plugin, if there is better plugin for the purpose.Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Joe,
I think most people would be happy to provide a reason, if you have it
listed.
It should be listed, because it should have been brought up during
discussion.Obviously we don't live in an ideal world, and you may get lots of no votes
still that don't provide a reason.
There are clear cases that people misunderstand proposals.
Recent example is PRNG adoption for uniqid(). I proposed patch does
not have any BC, but there were people opposed based on false FUD.
i.e. RPNG device access causes access error which is nothing to do
with internal function.
Another example is session ID validation. It is mandatory to keep
session as secure as possible, yet there are some people do not
realize(?) why it is mandatory. There is workaround, but I haven't
seen implementation does it correctly. I would rather just fix the
issue rather than trying to teach how to do it.
Anyway, regardless of opposition is reasonable or not, disclosing the
reason why it is not preferred is valuable. Could you at least state
in the RFC that all voters who are not in favor of the proposal should
disclose the reason?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
2016-11-18 22:10 GMT-04:00 Yasuo Ohgaki yohgaki@ohgaki.net:
Hi Joe,
On Sat, Nov 19, 2016 at 12:28 AM, Joe Watkins pthreads@pthreads.org
wrote:I think most people would be happy to provide a reason, if you have it
listed.
It should be listed, because it should have been brought up during
discussion.Obviously we don't live in an ideal world, and you may get lots of no
votes
still that don't provide a reason.There are clear cases that people misunderstand proposals.
Recent example is PRNG adoption for
uniqid(). I proposed patch does
not have any BC, but there were people opposed based on false FUD.
i.e. RPNG device access causes access error which is nothing to do
with internal function.Another example is session ID validation. It is mandatory to keep
session as secure as possible, yet there are some people do not
realize(?) why it is mandatory. There is workaround, but I haven't
seen implementation does it correctly. I would rather just fix the
issue rather than trying to teach how to do it.Anyway, regardless of opposition is reasonable or not, disclosing the
reason why it is not preferred is valuable. Could you at least state
in the RFC that all voters who are not in favor of the proposal should
disclose the reason?Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net--
Hi Yasuo,
In my opinion, this belongs to another RFC. Please, propose an optional way
for voters to input a small paragraph disclosing a justification upon
voting. We've seen many voices on this mailing list supporting this
proposal, perhaps it's time to discuss officially. Keep in mind this change
in the voting process requires the voting doodle to be customized somehow
(I don't know how).
Best regards,
Márcio.
Hi Yasuo,
In my opinion, this belongs to another RFC. Please, propose an optional way
for voters to input a small paragraph disclosing a justification upon
voting. We've seen many voices on this mailing list supporting this
proposal, perhaps it's time to discuss officially. Keep in mind this change
in the voting process requires the voting doodle to be customized somehow
(I don't know how).Best regards,
Márcio.
Explaining why someone votes against something makes voting against more
difficult than voting for.
I would suggest just increasing the margin to pass. That's a good way to
solve the issue, and the pros and cons can be discussed on the list.
Is it required to be a member of this list to vote? That too would be a
good idea if it isn't required, hopefully translators are accurate
enough to understand arguments here pro and con when not in a language
the voter has excellent grasp of.
Personally I abstain from voting because I do not feel qualified to make
decisions that impact the majority of PHP users, but some things I may
comment on, but only on this list.
2016-11-19 3:39 GMT+01:00 Alice Wonder alice@librelamp.com:
Is it required to be a member of this list to vote? That too would be a good
idea if it isn't required, hopefully translators are accurate enough to
understand arguments here pro and con when not in a language the voter has
excellent grasp of.
Only people with active VCS accounts or wiki accounts (that's been
approved) are allowed to vote.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
2016-11-19 3:39 GMT+01:00 Alice Wonder alice@librelamp.com:
Is it required to be a member of this list to vote? That too would be a good
idea if it isn't required, hopefully translators are accurate enough to
understand arguments here pro and con when not in a language the voter has
excellent grasp of.Only people with active VCS accounts or wiki accounts (that's been
approved) are allowed to vote.
Thank you, I knew there was an identity validation requirement, and that
makes sense.
I do know I enjoy reading the RFC discussions here on what is proposed
to be deprecated, it often has helped me realize there is a better way
to do something than the way I currently am doing something.
mcrypt for example, after reading about how stale it was, I didn't wait
to deprecate it on my own but just removed it from my php build - and
any web apps I install that want it, I fix.
Afternoon internals,
This has been discussed before in various RFC threads, there does seem to
be some consensus that 50%+1 votes could be harmful.To what degree, I am not sure.
I raise for discussion the topic of abolishing 50%+1 votes, and requiring
all changes regardless of their nature to pass by a super majority of
2/3+1.Please read the (brief) RFC and raise objections here.
There will be a one week discussion period for this RFC.
Thans for the RFC, Joe. I'm all for it, but maybe we should raise the
bar even higher (say, 75% as suggested by Dennis), and perhaps also
introduce a required minimum of votes (to avoid that a single yes vote
could decide over an RFC).
Anyhow, I would suggest to rewrite the introduction section – a PHP RFC
should better be concerned with PHP only. :-)
--
Christoph M. Becker
Afternoon Chrisoph,
The minimum number of votes is going to be the subject of another RFC,
let's leave that aside for now.
I've written many RFC's that change the language, the majority have failed.
Setting the bar high is the aim, and the bar feels high at 2/3+1, but
crucially, not higher than it should be.
Setting the bar too high is discouraging, I think: We don't want less
contributions, we want clearer outcomes.
Cheers
Joe
On Thu, Nov 17, 2016 at 5:57 PM, Christoph M. Becker cmbecker69@gmx.de
wrote:
Afternoon internals,
This has been discussed before in various RFC threads, there does seem to
be some consensus that 50%+1 votes could be harmful.To what degree, I am not sure.
I raise for discussion the topic of abolishing 50%+1 votes, and requiring
all changes regardless of their nature to pass by a super majority of
2/3+1.Please read the (brief) RFC and raise objections here.
There will be a one week discussion period for this RFC.
Thans for the RFC, Joe. I'm all for it, but maybe we should raise the
bar even higher (say, 75% as suggested by Dennis), and perhaps also
introduce a required minimum of votes (to avoid that a single yes vote
could decide over an RFC).Anyhow, I would suggest to rewrite the introduction section – a PHP RFC
should better be concerned with PHP only. :-)--
Christoph M. Becker
Afternoon Chrisoph,
The minimum number of votes is going to be the subject of another RFC,
let's leave that aside for now.
I'm not sure splitting this into lots of micro-decisions is wise: why
not discuss a general reform of the voting system, and have a single RFC
which can then document the agreed system, and supersede
https://wiki.php.net/rfc/voting?
This could then include:
- Clarifying who exactly can vote; the current definition is very
vague, and allows for wildly differing numbers of votes, making the next
two points much harder. - Should there be a "quorum" (minimum number of votes) required for a
vote to be passed? - What should be the minimum proportion of votes required for a
resolution to pass, given the decisions made under 1 and 2.
These issues are all interconnected - if you have a large voter base,
and a large quorum, then the difference between 50% and 66% is much higher.
Regards,
Rowan Collins
[IMSoP]
Afternoon Rowan,
The sum of their parts amounts to a substantial change in the way we
conduct development here.
If we are going to make changes, we should not draw out the process, but
nor should we have too much haste in making these decisions.
Having a one week discussion period is some kind of compromise between a
big RFC, and doing one thing at a time.
Let us consider each issue on it's own, make good decisions on each issue,
with clear majorities.
Cheers
Joe
On Thu, Nov 17, 2016 at 6:16 PM, Rowan Collins rowan.collins@gmail.com
wrote:
Afternoon Chrisoph,
The minimum number of votes is going to be the subject of another RFC,
let's leave that aside for now.I'm not sure splitting this into lots of micro-decisions is wise: why not
discuss a general reform of the voting system, and have a single RFC which
can then document the agreed system, and supersede
https://wiki.php.net/rfc/voting?This could then include:
- Clarifying who exactly can vote; the current definition is very vague,
and allows for wildly differing numbers of votes, making the next two
points much harder.- Should there be a "quorum" (minimum number of votes) required for a
vote to be passed?- What should be the minimum proportion of votes required for a
resolution to pass, given the decisions made under 1 and 2.These issues are all interconnected - if you have a large voter base, and
a large quorum, then the difference between 50% and 66% is much higher.Regards,
Rowan Collins
[IMSoP]
The sum of their parts amounts to a substantial change in the way we
conduct development here.
[...]
Let us consider each issue on it's own, make good decisions on each
issue, with clear majorities.
You seem to take the same basis as me, and reach the opposite
conclusion. I think there is substantial interaction between the
questions of who should vote, how they should vote, and how the vote
should be "won". Changing the process one variable at a time might lead
to combinations which would never have been reached in a unified
discussion.
I realise you've now said you're going to redraft the RFC with wider
scope, so I hope you'll consider bringing in some of the other elements
raised.
Regards,
--
Rowan Collins
[IMSoP]
Hi Rowan,
Rowan Collins wrote:
Afternoon Chrisoph,
The minimum number of votes is going to be the subject of another RFC,
let's leave that aside for now.I'm not sure splitting this into lots of micro-decisions is wise: why
not discuss a general reform of the voting system, and have a single RFC
which can then document the agreed system, and supersede
https://wiki.php.net/rfc/voting?
This might be a good idea, even if we only change the threshold.
A potential problem with our current system of policy RFCs is I don't
think can we amend existing ones, only pass new ones. This would mean
you'd have to refer to the Voting RFC and the new RFC (as proposed by
Joe) to understand the current policy, rather than it all being in one
place. Worse, if you just read the Voting RFC on its own, you wouldn't
know the threshold it specifies is no longer correct.
To compare to legal systems for a moment, they don't have to have this
problem. In the UK, we have Acts of Parliament, which pass and become
part of the law. But those acts can amend existing Acts that are already
part of the law, to keep things neat. That makes things simpler, because
when you want to know what the current law is, you only have to refer to
the existing Act as amended, not the existing Act and a new Act which
supplements and possibly overrides it. You can also of course replace
existing Acts entirely, or create new supplementary Acts, but you want
to avoid this when making small changes like the one Joe proposes.
Creating an RFC which would completely replace the Voting RFC would
avoid people having to refer to two RFCs, one of which overrides the other.
Alternatively, we could decide to do what the law does, and update the
Voting RFC in place once a new RFC passes, so the wiki page for it would
reflect the amended rules, not the RFC as it originally passed. This is
a wiki, so we do have revision control and could mention on the page
that it had been amended, and link to the original version. (This is,
incidentally, what the UK's legislation website does.)
Regards.
--
Andrea Faulds
https://ajf.me/
Afternoon Andrea,
Intention was to just update the voting page, and any other related docs
that might exist (maybe rfc template).
Cheers
Joe
Hi Rowan,
Rowan Collins wrote:
Afternoon Chrisoph,
The minimum number of votes is going to be the subject of another RFC,
let's leave that aside for now.I'm not sure splitting this into lots of micro-decisions is wise: why
not discuss a general reform of the voting system, and have a single RFC
which can then document the agreed system, and supersede
https://wiki.php.net/rfc/voting?This might be a good idea, even if we only change the threshold.
A potential problem with our current system of policy RFCs is I don't
think can we amend existing ones, only pass new ones. This would mean you'd
have to refer to the Voting RFC and the new RFC (as proposed by Joe) to
understand the current policy, rather than it all being in one place.
Worse, if you just read the Voting RFC on its own, you wouldn't know the
threshold it specifies is no longer correct.To compare to legal systems for a moment, they don't have to have this
problem. In the UK, we have Acts of Parliament, which pass and become part
of the law. But those acts can amend existing Acts that are already part of
the law, to keep things neat. That makes things simpler, because when you
want to know what the current law is, you only have to refer to the
existing Act as amended, not the existing Act and a new Act which
supplements and possibly overrides it. You can also of course replace
existing Acts entirely, or create new supplementary Acts, but you want to
avoid this when making small changes like the one Joe proposes.Creating an RFC which would completely replace the Voting RFC would avoid
people having to refer to two RFCs, one of which overrides the other.Alternatively, we could decide to do what the law does, and update the
Voting RFC in place once a new RFC passes, so the wiki page for it would
reflect the amended rules, not the RFC as it originally passed. This is a
wiki, so we do have revision control and could mention on the page that it
had been amended, and link to the original version. (This is, incidentally,
what the UK's legislation website does.)Regards.
--
Andrea Faulds
https://ajf.me/
Hi Joe,
Joe Watkins wrote:
Afternoon Andrea,
Intention was to just update the voting page, and any other related docs
that might exist (maybe rfc template).
Okay, that's fine. Make sure to mention on the voting RFC that it was
amended, then. :)
--
Andrea Faulds
https://ajf.me/
The study of voting systems is a hobby of mine and I've encoding vote
gathering algorithms implementing them before, so this gives me a bit of
insight into the discussion at hand that I would like to share. The goal
of any voting system is to reach a consensus, and while majority rule
(regardless of the amount of the majority) is appropriate for most issues,
it is not appropriate for all. Specifically, it fails to work in any
situation where the group is being asked to reach a consensus on three or
more choices.
Ironically the choice put forth in this thread is just such an instance.
Stay at 50%+1, Go to 2/3rds, 3/4ths has been mentioned and 3/5ths is
another commonly required ratio. Four choices.
The best method for dealing with this situation is a ranked choice ballot
and an instant run off vote. The ballot itself asks the voters to rank
their choices, not just stamp a single one. The votes are counted using the
expressed first choice on the ballot. If the measure doesn't pass then the
option with the fewest supporters is disqualified. The ballots for that
option are recounted and the 2nd choice is added to the counts. If the
measure still doesn't pass this process is repeated, recursively until
there are only two candidate, in which case the one with the majority wins.
This method doesn't work directly with methods requiring a plurality other
than a simple majority, but it isn't meant to be applied in the same
situations.
I'm putting this forward because I worry the group might paint themselves
into a corner by requiring all issues require a super majority, because
that's going to fall apart when there are three or more possibilities. The
methods can be combined, using ranked choice to determine which option will
be put up against the status quo, then a super majority vote to determine
if that option will be chosen over the status quo.
Hi,
Michael Morris wrote:
I'm putting this forward because I worry the group might paint themselves
into a corner by requiring all issues require a super majority, because
that's going to fall apart when there are three or more possibilities. The
methods can be combined, using ranked choice to determine which option will
be put up against the status quo, then a super majority vote to determine
if that option will be chosen over the status quo.
This is a fair point. There's also some types of vote (deciding between
two ways to implement something which is decided as happening) for which
a 2/3 majority doesn't make sense, because it biases it in favour of one
outcome.
--
Andrea Faulds
https://ajf.me/
Morning Micheal,
In general, we don't have RFC's that have many choices, nor do we for this
RFC.
We are only choosing between requiring 2/3's all the time, and not
requiring 2/3 all the time.
While it has been suggested that we raise the bar higher than our current
standards raise it, we won't be choosing between those options at vote
time, for the reasons I've already given.
I would rather coerce contributors into making simple votes with high
standards, than allow them to create very complicated voting options,
possibly with lower standards.
Cheers
Joe
The study of voting systems is a hobby of mine and I've encoding vote
gathering algorithms implementing them before, so this gives me a bit of
insight into the discussion at hand that I would like to share. The goal
of any voting system is to reach a consensus, and while majority rule
(regardless of the amount of the majority) is appropriate for most issues,
it is not appropriate for all. Specifically, it fails to work in any
situation where the group is being asked to reach a consensus on three or
more choices.Ironically the choice put forth in this thread is just such an instance.
Stay at 50%+1, Go to 2/3rds, 3/4ths has been mentioned and 3/5ths is
another commonly required ratio. Four choices.The best method for dealing with this situation is a ranked choice ballot
and an instant run off vote. The ballot itself asks the voters to rank
their choices, not just stamp a single one. The votes are counted using the
expressed first choice on the ballot. If the measure doesn't pass then the
option with the fewest supporters is disqualified. The ballots for that
option are recounted and the 2nd choice is added to the counts. If the
measure still doesn't pass this process is repeated, recursively until
there are only two candidate, in which case the one with the majority wins.This method doesn't work directly with methods requiring a plurality other
than a simple majority, but it isn't meant to be applied in the same
situations.I'm putting this forward because I worry the group might paint themselves
into a corner by requiring all issues require a super majority, because
that's going to fall apart when there are three or more possibilities. The
methods can be combined, using ranked choice to determine which option will
be put up against the status quo, then a super majority vote to determine
if that option will be chosen over the status quo.
The minimum number of votes is going to be the subject of another RFC,
let's leave that aside for now.
I'm not sure splitting this into lots of micro-decisions is wise: why not
discuss a general reform of the voting system, and have a single RFC which
can then document the agreed system, and supersede
https://wiki.php.net/rfc/voting?
I agree with this. We could end up with a different system if we look at
this holistically. Also, I'm not sure what the urgency in making this
change is. I'd rather be thoughtful about a substantive change like this.
It might help to articulate the goals of the voting system. I agree with
the gut feel that 50%+1 is a weak test, but that really depends on what's
being tested. If we can articulate goals in the RFC, that will also help
inform how the community approaches writing RFCs.
I have some concerns that a very high bar will make it difficult to change
extensions if their users aren't well-represented here.
Thanks,
Adam
I agree with this. We could end up with a different system if we look at
this holistically. Also, I'm not sure what the urgency in making this
change is. I'd rather be thoughtful about a substantive change like this.It might help to articulate the goals of the voting system. I agree with
the gut feel that 50%+1 is a weak test, but that really depends on what's
being tested. If we can articulate goals in the RFC, that will also help
inform how the community approaches writing RFCs.I have some concerns that a very high bar will make it difficult to change
extensions if their users aren't well-represented here.
My opinion, for what it's worth, is that simple majority should be
sufficient for any non-binding decision - that is a choice that doesn't
have BC breaks and further doesn't create future BC breaks if the measure
is voted out.
Simple majority should also be sufficient if there is no status quo other
than doing nothing and doing nothing isn't a viable choice.
Ranked choice ballots should be used when there are three or more competing
plans of action as it is better for reaching consensus in those situations.
These rules as well as who has a right to vote need to be more clearly
documented somewhere.
Hi Joe
2016-11-17 18:18 GMT+01:00 Joe Watkins pthreads@pthreads.org:
Afternoon internals,
This has been discussed before in various RFC threads, there does seem to
be some consensus that 50%+1 votes could be harmful.
I still stand by that we should only let active contributors to PHP
vote, while I understand that not everyone votes and there are many
projects within the PHP.net umbrella. I do understand that many from
outside projects wants to contribute and not everyone is great at C or
internals or similar, but it is us that maintain PHP and if everyone
who have a wiki account votes on something they may not understand the
implication of, then it us that sits with it for years to maintain.
By doing that I think we wouldn't need to have a X%+1 for accepting an
RFC, if there are a tie, then there is obviously a dispute among us
core developers and it can be discussed. Kinda what we used to do with
voting on the ML, just by tracking them on the wiki interface.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Afternoon Kalle,
We have to start with the assumption that everyone that votes, does so with
good intentions.
I'm sympathetic to the view that active contributors should somehow carry
more weight with their words, or vote. But, I shy away from actually saying
that we should only listen to those people.
Consider the case of an extension developer who may not have time to
actively contribute to php-src, but is directly affected by decisions we
make. They acquired karma for fixing a couple of bugs in the course of
developing their extension, and so vote when RFC's come along that they
have an opinion on. Their extension may be widely used, but just not a
candidate for inclusion in PHP.
I think we all intuitively agree that this person deserves their voice, and
that they can't be considered active contributors in any real sense.
Such cases are innumerable.
Cheers
Joe
Hi Joe
2016-11-17 18:18 GMT+01:00 Joe Watkins pthreads@pthreads.org:
Afternoon internals,
This has been discussed before in various RFC threads, there does seem to
be some consensus that 50%+1 votes could be harmful.I still stand by that we should only let active contributors to PHP
vote, while I understand that not everyone votes and there are many
projects within the PHP.net umbrella. I do understand that many from
outside projects wants to contribute and not everyone is great at C or
internals or similar, but it is us that maintain PHP and if everyone
who have a wiki account votes on something they may not understand the
implication of, then it us that sits with it for years to maintain.By doing that I think we wouldn't need to have a X%+1 for accepting an
RFC, if there are a tie, then there is obviously a dispute among us
core developers and it can be discussed. Kinda what we used to do with
voting on the ML, just by tracking them on the wiki interface.--
regards,Kalle Sommer Nielsen
kalle@php.net
2016-11-17 19:22 GMT+01:00 Joe Watkins pthreads@pthreads.org:
Afternoon Kalle,
We have to start with the assumption that everyone that votes, does so with
good intentions.
Ofcourse, but I just don't think it is fair that someone who made an
RFC and never contributed anything else to the project, can have an
impact on the future of PHP just because they got a wiki account or
someone who got a VCS account for a pear package they never released
10 years ago, but still got approved. I fully respect everyone who
have contributed to PHP now and in the past for all their hard work,
but I would also like to see a line drawn.
I'm sympathetic to the view that active contributors should somehow carry
more weight with their words, or vote. But, I shy away from actually saying
that we should only listen to those people.
I agree that we should listen to everyone, else it becomes this closed
gentleman's club it kinda used to be. Alternatively we can have a
community vote, which can be a factor to the end result ofcourse.
Consider the case of an extension developer who may not have time to
actively contribute to php-src, but is directly affected by decisions we
make. They acquired karma for fixing a couple of bugs in the course of
developing their extension, and so vote when RFC's come along that they have
an opinion on. Their extension may be widely used, but just not a candidate
for inclusion in PHP.I think we all intuitively agree that this person deserves their voice, and
that they can't be considered active contributors in any real sense.Such cases are innumerable.
That's a valid case and concern, but I think if it came down to
changing to something like active contributors, such cases like this
should be well written and how we can let such voices heard/matter,
maybe there could be a category, say someone wants to add a new
function to an extension, then everyone who contributes to that can
vote too (as in karma based) or if its an internal API change that can
affect extensions heavily.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
2016-11-17 19:45 GMT+01:00 Kalle Sommer Nielsen kalle@php.net:
2016-11-17 19:22 GMT+01:00 Joe Watkins pthreads@pthreads.org:
Afternoon Kalle,
We have to start with the assumption that everyone that votes, does so
with
good intentions.Ofcourse, but I just don't think it is fair that someone who made an
RFC and never contributed anything else to the project, can have an
impact on the future of PHP just because they got a wiki account or
Just a note: People with just wiki accounts can't vote currently:
https://wiki.php.net/rfc/voting#who_can_vote
Regards, Niklas
2016-11-19 12:18 GMT+01:00 Niklas Keller me@kelunik.com:
2016-11-17 19:45 GMT+01:00 Kalle Sommer Nielsen kalle@php.net:
2016-11-17 19:22 GMT+01:00 Joe Watkins pthreads@pthreads.org:
Afternoon Kalle,
We have to start with the assumption that everyone that votes, does so
with
good intentions.Ofcourse, but I just don't think it is fair that someone who made an
RFC and never contributed anything else to the project, can have an
impact on the future of PHP just because they got a wiki account orJust a note: People with just wiki accounts can't vote currently:
https://wiki.php.net/rfc/voting#who_can_voteRegards, Niklas
Hmm interesting, because I'm certain that in the past I have seen
people with just wiki accounts vote. I just had a look but I couldn't
find any such by browsing a few RFCs, maybe these records were removed
at one point? Oh well :)
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Afternoon internals,
This is not a new subject for discussion, it has been discussed over and
over, and I'm quite sure that many people had formed an opinion on 50%+1
votes before the RFC was posted.
One week to allow new points to be raised seems fair enough to me.
I didn't say there would be a shorter voting period, and I'm quite happy to
leave the vote open for two weeks to allow votes to come in.
This isn't a case where opinion is likely to change the content of the RFC:
I'm not looking to change a bunch of rules, or implement a very complicated
feature. We are only looking to answer the question "should we abolish
50%+1 votes" ...
For such a simple question, 3 weeks in total should be long enough.
Cheers
Joe
On Sat, Nov 19, 2016 at 11:37 AM, Kalle Sommer Nielsen kalle@php.net
wrote:
2016-11-19 12:18 GMT+01:00 Niklas Keller me@kelunik.com:
2016-11-17 19:45 GMT+01:00 Kalle Sommer Nielsen kalle@php.net:
2016-11-17 19:22 GMT+01:00 Joe Watkins pthreads@pthreads.org:
Afternoon Kalle,
We have to start with the assumption that everyone that votes, does so
with
good intentions.Ofcourse, but I just don't think it is fair that someone who made an
RFC and never contributed anything else to the project, can have an
impact on the future of PHP just because they got a wiki account orJust a note: People with just wiki accounts can't vote currently:
https://wiki.php.net/rfc/voting#who_can_voteRegards, Niklas
Hmm interesting, because I'm certain that in the past I have seen
people with just wiki accounts vote. I just had a look but I couldn't
find any such by browsing a few RFCs, maybe these records were removed
at one point? Oh well :)--
regards,Kalle Sommer Nielsen
kalle@php.net
For such a simple question, 3 weeks in total should be long enough.
Is this simply ... Every element of a vote has to achieve 2/3rds?
While there are many cases where a simple yes/no question can eventually
be agreed on, and I would prefer that some of the 50/50 decisions had a
much greater consensus, areas where there is no clean consensus will not
be solved 'simply' by moving the goal posts?
The main problem is simply that there is not a common consensus on just
how PHP should develop, and things like 'who can vote' and getting a
sensible number of people to agree on something is just as important.
The recent RFC on 'Debugging PDO Prepared Statement' is a good example
of where people who may be affected have no vote, but people who could
properly assess the now approved patch don't have the time or incentive
to do so.
A number of current RFC's have overlapping elements where a consensus on
the base approach may be of more use than patching individual parts in
isolation. A vote on the 'roadmap' element with sub sections on elements
which may well not be appropriate for a full 3/2rds in light of the main
question.
--
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
Afternoon Lester,
Is this simply ... Every element of a vote has to achieve 2/3rds?
Yes, it is.
But before you rubbish that idea as ridiculous, think about what it really
means.
It doesn't mean that people will continue to open a 2/3 vote and then pin a
list of subsidiary decisions onto the voting stage.
It does mean that the author of the RFC is forced to open a vote with
clear, simple options, that must be acceptable to a real majority for the
motion to pass.
The aim here is only to raise standards by changing our criteria for
acceptance, it's one simple move.
It has side effects for RFC authors, obviously, which they may first view
as negative, but unarguably has a net positive effect for everyone else.
Cheers
Joe
For such a simple question, 3 weeks in total should be long enough.
Is this simply ... Every element of a vote has to achieve 2/3rds?
While there are many cases where a simple yes/no question can eventually
be agreed on, and I would prefer that some of the 50/50 decisions had a
much greater consensus, areas where there is no clean consensus will not
be solved 'simply' by moving the goal posts?The main problem is simply that there is not a common consensus on just
how PHP should develop, and things like 'who can vote' and getting a
sensible number of people to agree on something is just as important.
The recent RFC on 'Debugging PDO Prepared Statement' is a good example
of where people who may be affected have no vote, but people who could
properly assess the now approved patch don't have the time or incentive
to do so.A number of current RFC's have overlapping elements where a consensus on
the base approach may be of more use than patching individual parts in
isolation. A vote on the 'roadmap' element with sub sections on elements
which may well not be appropriate for a full 3/2rds in light of the main
question.--
Lester Caine - G8HFLContact - 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
Afternoon Lester,
Is this simply ... Every element of a vote has to achieve 2/3rds?
Yes, it is.
But before you rubbish that idea as ridiculous, think about what it really
means.It doesn't mean that people will continue to open a 2/3 vote and then pin a
list of subsidiary decisions onto the voting stage.It does mean that the author of the RFC is forced to open a vote with
clear, simple options, that must be acceptable to a real majority for the
motion to pass.The aim here is only to raise standards by changing our criteria for
acceptance, it's one simple move.It has side effects for RFC authors, obviously, which they may first view
as negative, but unarguably has a net positive effect for everyone else.Cheers
Joe
Wait ... what?
I assumed that this proposal only pertained to primary RFC acceptance
votes, not to secondary votes. I don't see how 2/3 majorities make sense
there. You'd either skew in favor of one option, or you'd end up in a
situation where an RFC is accepted, but one sub-question has not been
resolved (with supermajority) towards either option.
Nikita
Afternoon Nikita,
Why does there need to be sub-questions ?
If there needs be sub-questions, and they are resolved by only a slim
majority, then do you have the kind of consensus you should need to act ?
Cheers
Joe
On Sat, Nov 19, 2016 at 2:03 PM, Joe Watkins pthreads@pthreads.org
wrote:Afternoon Lester,
Is this simply ... Every element of a vote has to achieve 2/3rds?
Yes, it is.
But before you rubbish that idea as ridiculous, think about what it really
means.It doesn't mean that people will continue to open a 2/3 vote and then pin
a
list of subsidiary decisions onto the voting stage.It does mean that the author of the RFC is forced to open a vote with
clear, simple options, that must be acceptable to a real majority for the
motion to pass.The aim here is only to raise standards by changing our criteria for
acceptance, it's one simple move.It has side effects for RFC authors, obviously, which they may first view
as negative, but unarguably has a net positive effect for everyone else.Cheers
JoeWait ... what?
I assumed that this proposal only pertained to primary RFC acceptance
votes, not to secondary votes. I don't see how 2/3 majorities make sense
there. You'd either skew in favor of one option, or you'd end up in a
situation where an RFC is accepted, but one sub-question has not been
resolved (with supermajority) towards either option.Nikita
Afternoon internals,
I was wrong about it not changing, and wrong about only needing a week.
In fact, after some more thinking time, and re-reading everything here,
I'll present a revised, slightly larger RFC.
We'll start discussion, for the full two weeks, from the beginning, when
revised RFC is ready ...
Sorry about the noise, and thanks for all your input so far ...
I'll be back ...
Cheers
Joe
Afternoon Nikita,
Why does there need to be sub-questions ?
If there needs be sub-questions, and they are resolved by only a slim
majority, then do you have the kind of consensus you should need to act ?Cheers
JoeOn Sat, Nov 19, 2016 at 1:27 PM, Nikita Popov nikita.ppv@gmail.com
wrote:On Sat, Nov 19, 2016 at 2:03 PM, Joe Watkins pthreads@pthreads.org
wrote:Afternoon Lester,
Is this simply ... Every element of a vote has to achieve 2/3rds?
Yes, it is.
But before you rubbish that idea as ridiculous, think about what it
really
means.It doesn't mean that people will continue to open a 2/3 vote and then
pin a
list of subsidiary decisions onto the voting stage.It does mean that the author of the RFC is forced to open a vote with
clear, simple options, that must be acceptable to a real majority for the
motion to pass.The aim here is only to raise standards by changing our criteria for
acceptance, it's one simple move.It has side effects for RFC authors, obviously, which they may first view
as negative, but unarguably has a net positive effect for everyone else.Cheers
JoeWait ... what?
I assumed that this proposal only pertained to primary RFC acceptance
votes, not to secondary votes. I don't see how 2/3 majorities make sense
there. You'd either skew in favor of one option, or you'd end up in a
situation where an RFC is accepted, but one sub-question has not been
resolved (with supermajority) towards either option.Nikita
But before you rubbish that idea as ridiculous, think about what it really
means.
? I'm quite happy with the idea ... all I was rubbishing is the idea
that it's a 'simple' change, but you seem to have realised that now?
My only problem is with the way the language is being pushed without a
substantial consensus that requires the the rules get more discussion
than getting back to a 'simple' novice friendly version of PHP.
--
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
-----Original Message-----
From: kalle.php@gmail.com [mailto:kalle.php@gmail.com] On Behalf Of Kalle
Sommer Nielsen
Sent: Thursday, November 17, 2016 8:46 PM
To: Joe Watkins pthreads@pthreads.org
Cc: PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Abolish 50%+1 Votes2016-11-17 19:22 GMT+01:00 Joe Watkins pthreads@pthreads.org:
Afternoon Kalle,
We have to start with the assumption that everyone that votes, does so
with good intentions.Ofcourse, but I just don't think it is fair that someone who made an RFC and
never contributed anything else to the project, can have an impact on the future
of PHP just because they got a wiki account or someone who got a VCS account
for a pear package they never released
10 years ago, but still got approved. I fully respect everyone who have
contributed to PHP now and in the past for all their hard work, but I would also
like to see a line drawn.I'm sympathetic to the view that active contributors should somehow
carry more weight with their words, or vote. But, I shy away from
actually saying that we should only listen to those people.I agree that we should listen to everyone, else it becomes this closed gentleman's
club it kinda used to be. Alternatively we can have a community vote, which can
be a factor to the end result ofcourse.
FWIW, the current situation when everyone that has a VCS account gets an equal vote to someone with a thousand commits to php-src was never intended.
The Voting RFC talked about code contributors, and when it was discussed verbally - we agreed we'll come up with specific criteria to what that means. That never happened, and instead, the voting system was rolled out simplistically giving voting rights to anybody with a VCS account or even wiki access. In the same way, we agreed to provide leaders of OS projects and prominent Internals contributors a right to vote - and here too, we agreed (outside the scope of the RFC) that we'd come up with criteria for that, but we never did. Long story short, what ended up happening de-facto with the Voting RFC was very very different from the discussed intent. If all those 'TBDs' strike you as odd, note that before the Voting RFC, things were waaay less formal in the PHP world, and I, for one, was surprised at how quickly the Voting RFC (as well as other RFCs) as well as the newly-created status-quo that followed it became somewhat of a constitution or a bible. If you take a look at it (wiki.php.net/rfc/voting), even with a quick glance it's clear it was basically a pretty much first draft, that miraculously became unanimously approved despite lacking clear definitions and depth, and containing many flaws.
I think it's much more difficult to fix it today, but I still think it's worth it. E.g., regarding the Community voice, we could perhaps provide FIG reps with voting rights, and practically say they represent the community at large - instead of the vague and inactionable language we have there today. We didn't have that option back in 2011. We now also have github, where we can easily check the level of contribution of each VCS holder, and perhaps come up with a certain bar on what constitutes enough contribution for a vote. Those are of course just ideas, perhaps we can come up with better ones.
Ultimately, who gets to vote should be better defined; Pass criteria should be better defined (in the neighborhood of what Joe's doing) along with different types of votes; And we should also clarify how these rules can be amended. Ultimately, all of these are at least somewhat inter-connected.
Zeev
Afternoon Zeev,
I am not sure how much of the voting RFC I want to reform right now. I am
responding to specific problems that seem to be best fixed just by raising
the acceptance criteria. I do realize that these issues are difficult to
tease apart however, so intend to at least try to suggest reformations for
more than one section of the voting RFC.
Maybe it is time to have some of these conversations again. We do need to
decide between us what is a legitimate contributor and what is not, in
addition to who has a legitimate stake (such a FIG reps) ... All of us
probably have ideas about that, but there isn't any consensus, so it's hard
to suggest a change in this area. If a clear consensus emerged from
discussion back then, it is reasonable to assume a clear consensus would
emerge today, even if it changed.
When you say that the voting RFC was rushed, this is news to me. Perhaps
you can understand it being treated as a bible if you consider that we
don't remember the bad old days, and these are the only rules we know how
to play by. When new contributors come along, they don't have the benefit
brought by the historical knowledge of PHP, they have to read the words in
these RFC's and take them as ... gospel.
I'm pleased to hear more ideas whatever.
Cheers
Joe
-----Original Message-----
From: kalle.php@gmail.com [mailto:kalle.php@gmail.com] On Behalf Of
Kalle
Sommer Nielsen
Sent: Thursday, November 17, 2016 8:46 PM
To: Joe Watkins pthreads@pthreads.org
Cc: PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Abolish 50%+1 Votes2016-11-17 19:22 GMT+01:00 Joe Watkins pthreads@pthreads.org:
Afternoon Kalle,
We have to start with the assumption that everyone that votes, does so
with good intentions.Ofcourse, but I just don't think it is fair that someone who made an RFC
and
never contributed anything else to the project, can have an impact on
the future
of PHP just because they got a wiki account or someone who got a VCS
account
for a pear package they never released
10 years ago, but still got approved. I fully respect everyone who have
contributed to PHP now and in the past for all their hard work, but I
would also
like to see a line drawn.I'm sympathetic to the view that active contributors should somehow
carry more weight with their words, or vote. But, I shy away from
actually saying that we should only listen to those people.I agree that we should listen to everyone, else it becomes this closed
gentleman's
club it kinda used to be. Alternatively we can have a community vote,
which can
be a factor to the end result ofcourse.FWIW, the current situation when everyone that has a VCS account gets an
equal vote to someone with a thousand commits to php-src was never intended.The Voting RFC talked about code contributors, and when it was discussed
verbally - we agreed we'll come up with specific criteria to what that
means. That never happened, and instead, the voting system was rolled out
simplistically giving voting rights to anybody with a VCS account or even
wiki access. In the same way, we agreed to provide leaders of OS projects
and prominent Internals contributors a right to vote - and here too, we
agreed (outside the scope of the RFC) that we'd come up with criteria for
that, but we never did. Long story short, what ended up happening de-facto
with the Voting RFC was very very different from the discussed intent. If
all those 'TBDs' strike you as odd, note that before the Voting RFC, things
were waaay less formal in the PHP world, and I, for one, was surprised at
how quickly the Voting RFC (as well as other RFCs) as well as the
newly-created status-quo that followed it became somewhat of a constitution
or a bible. If you take a look at it (wiki.php.net/rfc/voting), even
with a quick glance it's clear it was basically a pretty much first draft,
that miraculously became unanimously approved despite lacking clear
definitions and depth, and containing many flaws.I think it's much more difficult to fix it today, but I still think it's
worth it. E.g., regarding the Community voice, we could perhaps provide
FIG reps with voting rights, and practically say they represent the
community at large - instead of the vague and inactionable language we have
there today. We didn't have that option back in 2011. We now also have
github, where we can easily check the level of contribution of each VCS
holder, and perhaps come up with a certain bar on what constitutes enough
contribution for a vote. Those are of course just ideas, perhaps we can
come up with better ones.Ultimately, who gets to vote should be better defined; Pass criteria
should be better defined (in the neighborhood of what Joe's doing) along
with different types of votes; And we should also clarify how these rules
can be amended. Ultimately, all of these are at least somewhat
inter-connected.Zeev
From: Joe Watkins [mailto:pthreads@pthreads.org]
Sent: Sunday, November 20, 2016 3:43 PM
To: Zeev Suraski zeev@zend.com
Cc: Kalle Sommer Nielsen kalle@php.net; PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Abolish 50%+1 Votes
Afternoon Zeev,
I am not sure how much of the voting RFC I want to reform right now. I am responding to specific problems
that seem to be best fixed just by raising the acceptance criteria. I do realize that these issues are difficult to
tease apart however, so intend to at least try to suggest reformations for more than one section of the
voting RFC.
Yes, I can relate to not wanting to tackle more than one issue at a given time. I think that depending on the proposal, it may be reasonable to tackle a change in what requires a super majority independently of other issues, without radically changing the current situation of how things work.
My bigger concern is that conceptually, the way things work currently is very far from the original intent of the Voting RFC. I'm at least am not aware of any other large open source project out there that has something that's even remotely close to what we evolved into in the PHP project. The vast majority of community-based open source projects are various forms of meritocracy, where your ability to influence the direction correlates in some fashion with your level of contribution. In PHP the barrier to influence is almost not there. There are several ways to tackle this - one is one I brought up a while ago, that effectively raises the acceptance bar from 2/3 to 85-90% - given that the vast majority of proposals that passed, didn't only pass with ~2/3 of the votes, but with something much close to consensus (reminder - see the analysis and proposals in internals@lists.php.net/msg82852.html" rel="nofollow" target="_blank">www.mail-archive.com/internals@lists.php.net/msg82852.html). A different way may be changing the (de-facto) rules on who gets to vote. Or perhaps a combination of both.
Maybe it is time to have some of these conversations again.
I think it is. As draining as it may be, I think we owe it to ourselves and PHP to try and tackle some of the deficiencies of the rushed Voting RFC, before it's even later than it already is...
When you say that the voting RFC was rushed, this is news to me.
In my opinion it was rushed.
By the time we started working on it, we had about 13 years of working in a certain way, which obviously evolved over time, but was never ever even remotely similar to what's described in the Voting RFC. And then, over the course of less than a month, we had a piece of text that a bunch of people agreed on (with some major reservations), that was as hermetic as a thing slice of Swiss cheese; A completely different way of working quickly evolved, somewhat based on a very broadening interpretation of that text - and that new way of working became set in stone.
Looking back at my email archive, I think we did recognize that there were some tricky parts in this RFC, and that it would be very difficult to change:
"Making changes once we've approved this RFC is going to be much tougher. This is big stuff - it's no coincidence we didn't have such guidelines for almost 15 years.
Honestly there are other parts about the voting process that are much hotter potatoes than the points I brought up - such as who gets to vote, is 50%+1 enough or do we need stronger majorities for substantial language changes (67%/75%), can someone who failed passing an RFC just put it up for another vote right away or is there some sort of a cool-off period, etc. etc. I think all of these need to be answered before we let this RFC govern how we do feature definition."
... and yet, there was a very strong bias to get something going, so my barely-first-draft on dealing with some of these topics became set in stone, with very few updates and little scrutiny from anybody. I think that there were large groups of people who believed (based on the discussion on the list) that we'd still first strive for near-consensus before even bringing up RFCs for voting, which as we all know - turned out to be very far from what happened in reality. Others thought that it wouldn't be a big deal to amend and improve this as we go along - which also turned out to be disconnected from reality as not a single change was made in the last 5 years (except the de-facto changes, like who gets to vote).
I think the feeling back then was that "anything is better than nothing", and perhaps it was - but it certainly pushed us to move ahead with a half-baked solution. This RFC went to a vote two weeks after I made these statements and made my edits, with virtually no further discussion on internals during these two weeks, and was approved 6 days later. Yes, I'd call it rushed.
Perhaps you can understand it being treated as a bible if you consider that we don't remember the bad old days, and these are the only rules we know how to play by.
Oh I certainly do. As you can see in my quote, I expected it to become that way. What I didn't expect us to do is ratify it so quickly, when it was only slightly better baked than when I made that statement... That's the same reason I was worried about other non-technical proposals that were raised over the years - I just don't think we're very good at this law-making stuff.
Zeev
Afternoon internals,
This has been discussed before in various RFC threads, there does seem to
be some consensus that 50%+1 votes could be harmful.To what degree, I am not sure.
I raise for discussion the topic of abolishing 50%+1 votes, and requiring
all changes regardless of their nature to pass by a super majority of
2/3+1.Please read the (brief) RFC and raise objections here.
There will be a one week discussion period for this RFC.
Cheers
Joe
A technical note: The existing supermajority requirement is >= 2/3, not >=
2/3+1. I think that should stay the same.
Apart from that, I totally agree that everything should take a 2/3
majority. It simplifies the rules and avoids the common and very pointless
discussion about what exactly constitutes a "language change". I have the
vague impression that this issue has come up on pretty much every major
RFC (like phpng -- Is it really a language change if it's just internals?
Similar for int size changes. Similar for PHP 6 vs 7, etc.)
Nikita
Afternoon Nikita,
My mistake, changing that ...
Cheers
Joe
On Thu, Nov 17, 2016 at 6:18 PM, Joe Watkins pthreads@pthreads.org
wrote:Afternoon internals,
This has been discussed before in various RFC threads, there does seem to
be some consensus that 50%+1 votes could be harmful.To what degree, I am not sure.
I raise for discussion the topic of abolishing 50%+1 votes, and requiring
all changes regardless of their nature to pass by a super majority of
2/3+1.Please read the (brief) RFC and raise objections here.
There will be a one week discussion period for this RFC.
Cheers
JoeA technical note: The existing supermajority requirement is >= 2/3, not >=
2/3+1. I think that should stay the same.Apart from that, I totally agree that everything should take a 2/3
majority. It simplifies the rules and avoids the common and very pointless
discussion about what exactly constitutes a "language change". I have the
vague impression that this issue has come up on pretty much every major
RFC (like phpng -- Is it really a language change if it's just internals?
Similar for int size changes. Similar for PHP 6 vs 7, etc.)Nikita
2016-11-17 18:18 GMT+01:00 Joe Watkins pthreads@pthreads.org:
Afternoon internals,
This has been discussed before in various RFC threads, there does seem to
be some consensus that 50%+1 votes could be harmful.To what degree, I am not sure.
I raise for discussion the topic of abolishing 50%+1 votes, and requiring
all changes regardless of their nature to pass by a super majority of
2/3+1.Please read the (brief) RFC and raise objections here.
There will be a one week discussion period for this RFC.
Cheers
Joe
What's the reason for 2/3+1 instead of 2/3? Currently we have 50%+1 or 2/3,
but not 2/3+1 as 2/3 is already a majority.
Regards, Niklas
Afternoon Niklas,
I made an off-by-one error in an RFC.
Thanks for captioning my pain.
Cheers
Joe
2016-11-17 18:18 GMT+01:00 Joe Watkins pthreads@pthreads.org:
Afternoon internals,
This has been discussed before in various RFC threads, there does seem to
be some consensus that 50%+1 votes could be harmful.To what degree, I am not sure.
I raise for discussion the topic of abolishing 50%+1 votes, and requiring
all changes regardless of their nature to pass by a super majority of
2/3+1.Please read the (brief) RFC and raise objections here.
There will be a one week discussion period for this RFC.
Cheers
JoeWhat's the reason for 2/3+1 instead of 2/3? Currently we have 50%+1 or
2/3, but not 2/3+1 as 2/3 is already a majority.Regards, Niklas
2016-11-17 13:18 GMT-04:00 Joe Watkins pthreads@pthreads.org:
Afternoon internals,
This has been discussed before in various RFC threads, there does seem to
be some consensus that 50%+1 votes could be harmful.To what degree, I am not sure.
I raise for discussion the topic of abolishing 50%+1 votes, and requiring
all changes regardless of their nature to pass by a super majority of
2/3+1.Please read the (brief) RFC and raise objections here.
There will be a one week discussion period for this RFC.
Cheers
Joe
Hi Joe,
I fully support the change to always require super majority on all votings.
Sometimes RFCs don't contain a language change (by the criteria defined on
our wiki) but can contain BC breaks. I used to believe the RFC authors
would have the sensibility to always raise the bar higher in these cases,
but it's much better to change the system to enforce super majority IMMO.
About the requests to have 75%+1 votes, I believe raising the bar too high
could be damaging when entering a new major release in the future. But
perhaps RFC authors that stand for 75%+1 voting could propose RFCs with
that ratio instead of 2/3+1 if they think it's necessary.
PS: I wonder if the voting to change the process to always require 2/3+1
will be a 50%+1 poll? :P
Ty,
Márcio Almada.
Afternoon internals,
This has been discussed before in various RFC threads, there does seem to
be some consensus that 50%+1 votes could be harmful.To what degree, I am not sure.
I raise for discussion the topic of abolishing 50%+1 votes, and requiring
all changes regardless of their nature to pass by a super majority of
2/3+1.Please read the (brief) RFC and raise objections here.
There will be a one week discussion period for this RFC.
Cheers
Joe
As I have voiced in the past I completely agree with moving to >= 2/3.
I would also consider supporting >= 3/4. I believe that PHP is at a
point in its lifetime that new features or changes should not be
considered lightly, which is why I would consider supporting something
more strict than 2/3.
Good afternoon,
There will be a one week discussion period for this RFC.
Sorry but the minimum discussion period for RFC is two weeks. No exception.
I will reply later for the feedback on the RFC :)
Cheers
Pierre
Morning Pierre,
That's not what the rules say.
There will be a one week discussion period.
Cheers
Joe
Good afternoon,
There will be a one week discussion period for this RFC.
Sorry but the minimum discussion period for RFC is two weeks. No exception.
I will reply later for the feedback on the RFC :)
Cheers
Pierre
Morning Pierre,
That's not what the rules say.
There will be a one week discussion period.
Cheers
JoeGood afternoon,
There will be a one week discussion period for this RFC.
Sorry but the minimum discussion period for RFC is two weeks. No exception.
I will reply later for the feedback on the RFC :)
Cheers
Pierre
See https://wiki.php.net/rfc/howto; it does say two weeks minimum in
step 6. If you know of anywhere it says one week please let me know.
Morning Pierre,
That's not what the rules say.
There will be a one week discussion period.
Sorry but no.
Morning Pierre,
Sorry, but yes.
http://wiki.php.net/rfc/voting
There'd be a minimum of 2 weeks between when an RFC that touches the
language is brought up on this list and when it's voted on is required.
Other RFCs might use a smaller timeframe, but it should be at least a week.
Cheers
Joe
Morning Pierre,
That's not what the rules say.
There will be a one week discussion period.
Sorry but no.
Morning Pierre,
Sorry, but yes.
http://wiki.php.net/rfc/voting
There'd be a minimum of 2 weeks between when an RFC that touches the
language is brought up on this list and when it's voted on is required.
Other RFCs might use a smaller timeframe, but it should be at least a week.
Seriously Joe, this is ridiculous. You are forcing a shorter period of time
for something that does affect PHP at a whole.
Be fair and let anyone raises their feedback.
Morning Pierre,
Sorry, but yes.
http://wiki.php.net/rfc/voting
There'd be a minimum of 2 weeks between when an RFC that touches the
language is brought up on this list and when it's voted on is required.
Other RFCs might use a smaller timeframe, but it should be at least a week.Seriously Joe, this is ridiculous. You are forcing a shorter period of time
for something that does affect PHP at a whole.Be fair and let anyone raises their feedback.
Ignoring whether this RFC "touches the language" (phrasing I've always
taken issue with) and as such requires a two-week discussion period. I
think this particular RFC should be given two weeks, or longer, for
everyone to have their say.
Given that it is Thanksgiving next week, for purely practical reasons, I
think it necessitates a longer discussion period (than one week) as
interested parties may simply not be around at all. For a process-related
RFC such as this, forcing a one-week discussion period when a large number
of folks mightn't even be looking at the list, reads as irresponsible, to
me at least.
Regards,
Peter (who apologises in advance for poking the bear)
Hi all,
Morning Pierre,
Sorry, but yes.
http://wiki.php.net/rfc/voting
There'd be a minimum of 2 weeks between when an RFC that touches the
language is brought up on this list and when it's voted on is required.
Other RFCs might use a smaller timeframe, but it should be at least a week.Seriously Joe, this is ridiculous. You are forcing a shorter period of time
for something that does affect PHP at a whole.Be fair and let anyone raises their feedback.
I don't look internal list weeks sometimes.
2 weeks is reasonable period for me, not too long nor too short.
I guess a week is too short during holiday season for most people.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi!
Sorry, but yes.
http://wiki.php.net/rfc/voting
There'd be a minimum of 2 weeks between when an RFC that touches the
language is brought up on this list and when it's voted on is required.
Other RFCs might use a smaller timeframe, but it should be at least a week.
I must say I don't understand Joe's position here. Where's the fire? Why
can't we afford two-week or three-week discussion? How does it make
sense to make a huge change in voting rules after tiniest amount of
discussion possible? If anything, we should take as long as it requires
for such things, not try to rush it through. I think minimal discussion
time is way unadequate for such thing. It's not adding optional argument
for an obscure PDO function, it's changing the rules for the whole
project. I see absolutely no reason not to let the discussion unfold and
be as long as it needs to be.
Stas Malyshev
smalyshev@gmail.com
-----Original Message-----
From: Joe Watkins [mailto:pthreads@pthreads.org]
Sent: Saturday, November 19, 2016 6:11 AM
To: Pierre Joye pierre.php@gmail.com
Cc: PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Abolish 50%+1 VotesMorning Pierre,
That's not what the rules say.
There will be a one week discussion period.
Cheers
Joe,
Changing the rules should at the very least be as long as the longest discussion period and the highest majority defined in the Voting RFC, and arguably, longer (which I think it should be here). It's really not sensible otherwise - a group with a simple majority could change the voting rules to require only a simple majority for everything, and pass whatever RFC it wants with a simple majority. Changing the rules is bigger than any single language-level decision, as it effects all future decisions going forward.
The original Voting RFC was rushed, and we're all still suffering from the consequences many years later. There's really no need to do it again.
Regarding the substance of the RFC, I think Andrea and perhaps others touched on an issue - a 2/3 majority doesn't make sense for situations when we need to pick an option, when none of the options has any inherent bias towards them.
When we deal with features, we did define a bias-for-status-quo, which means a 2/3 majority is needed to change it. I agree that the definition of 'features that change the language' is a poorly phrased one (file under 'rushed'), and that other types of features should also be passed in a 2/3 vote.
However, there are decisions which really boil down to nothing more than an opinion, where even if the status quo exists or is implied - there's no inherent difference between the choices. For example, the decision on how to version PHPNG that we faced about a year and a half ago. Should '7' have required a 2/3 majority, because '6' is the perceived default? I would disagree. It's a simple matter of opinion, doesn't change the language in any way, and 6 isn't more 'status quo' than 7 in any way that 7 is more than 6. Also, other administrative decisions, such as delaying a release for whatever reasons (like we did for the inclusion of OPcache, IIRC) - should also be a simple majority.
I think the test that Michael brought up - "does it have any backwards compatibility or forwards compatibility implications?", is probably the right one to have. In other words - if it breaks BC, it requires a supermajority. If it adds something that, if removed/changed in the future, would introduce BC - it requires supermajority. Otherwise - it's a simple majority (>50%, or even just the option that got the most votes in case of a 3-way or 4-way vote). On top of that, to clarify, the rules themselves should definitely require supermajority to change (arguably higher than the current 2/3 we have; the original Voting RFC was passed in consensus).
Zeev
Afternoon Zeev,
It first seemed like a very simple question to abolish 50%+1 votes, it
quickly become apparent that this is not viable in any sense.
Maybe I should have spotted that it wasn't sensible, maybe Pierre did and
thought I was crazy, maybe Pierre thought I had spotted it but didn't care
... I was just late to realise that what I was suggesting doesn't make
sense :)
I did later reply that I intend to properly review mine and other's ideas,
and will be back with suggestions.
Thanks for your input.
Cheers
Joe
-----Original Message-----
From: Joe Watkins [mailto:pthreads@pthreads.org]
Sent: Saturday, November 19, 2016 6:11 AM
To: Pierre Joye pierre.php@gmail.com
Cc: PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Abolish 50%+1 VotesMorning Pierre,
That's not what the rules say.
There will be a one week discussion period.
Cheers
Joe,
Changing the rules should at the very least be as long as the longest
discussion period and the highest majority defined in the Voting RFC, and
arguably, longer (which I think it should be here). It's really not
sensible otherwise - a group with a simple majority could change the voting
rules to require only a simple majority for everything, and pass whatever
RFC it wants with a simple majority. Changing the rules is bigger than any
single language-level decision, as it effects all future decisions going
forward.The original Voting RFC was rushed, and we're all still suffering from the
consequences many years later. There's really no need to do it again.Regarding the substance of the RFC, I think Andrea and perhaps others
touched on an issue - a 2/3 majority doesn't make sense for situations when
we need to pick an option, when none of the options has any inherent bias
towards them.When we deal with features, we did define a bias-for-status-quo, which
means a 2/3 majority is needed to change it. I agree that the definition
of 'features that change the language' is a poorly phrased one (file under
'rushed'), and that other types of features should also be passed in a 2/3
vote.However, there are decisions which really boil down to nothing more than
an opinion, where even if the status quo exists or is implied - there's no
inherent difference between the choices. For example, the decision on how
to version PHPNG that we faced about a year and a half ago. Should '7'
have required a 2/3 majority, because '6' is the perceived default? I
would disagree. It's a simple matter of opinion, doesn't change the
language in any way, and 6 isn't more 'status quo' than 7 in any way that 7
is more than 6. Also, other administrative decisions, such as delaying a
release for whatever reasons (like we did for the inclusion of OPcache,
IIRC) - should also be a simple majority.I think the test that Michael brought up - "does it have any backwards
compatibility or forwards compatibility implications?", is probably the
right one to have. In other words - if it breaks BC, it requires a
supermajority. If it adds something that, if removed/changed in the
future, would introduce BC - it requires supermajority. Otherwise - it's a
simple majority (>50%, or even just the option that got the most votes in
case of a 3-way or 4-way vote). On top of that, to clarify, the rules
themselves should definitely require supermajority to change (arguably
higher than the current 2/3 we have; the original Voting RFC was passed in
consensus).Zeev
Otherwise - it's a simple majority (>50%, or even just the option that got
the most votes in case of a 3-way or 4-way vote).
There are better options for choices of 3 or more than the most votes
system and I strongly recommend that they be used. Allow me to present an
example.
Suppose we needed to include new functionality in PHP, and there where
three libraries available to provide it. A is the oldest and most mature
but hasn't been maintained in awhile. B is a less stable fork but has more
active maintenance. A & B have the same API. C is the newest cutting edge
version, but has a different API.
A vote is held. 32% for A, 31% B and 37% for C. C wins in this scenario
because the majority was split across the two similar choices A & B. If
ranked choice ballots were used in this scenario B would be eliminated on
the first round and the second choices of those ballots would be examined
with an end result of 58% for A, 42% for C, meaning most of the supporters
of B would settle for A but didn't really like C.
A lot of the bad blood in American politics can be directly linked to this
problem - splitting a majority in 3 or more way races. Political parties
arose specifically to prevent this splitting, but its a case that the cure
is worse than the disease. I don't think PHP is in any danger of devolving
into this sort of acrimony, but it's still worth avoiding the problem
entirely with ranked choice balloting where appropriate.