Afternoon internals,
I'd like to bring https://wiki.php.net/rfc/abolish-narrow-margins to vote
in the very near future ...
We discussed it a year ago, and discussion died down to nothing (possibly
because it was sidetracked); If there are no objections I'll bring it to
vote in the coming days ...
Cheers
Joe
I'd like to bring https://wiki.php.net/rfc/abolish-narrow-margins to vote
in the very near future ...We discussed it a year ago, and discussion died down to nothing (possibly
because it was sidetracked); If there are no objections I'll bring it to
vote in the coming days ...
"The current political climate of Earth shows us that votes that are
won by narrow margins build resentment among voters, can lead to
instability in the ecosphere, and could be considered harmful to
democracy."
Snicker... I want to vote for this purely to make that sentence part
of our bylaws.
In all seriousness though, I'm in favor of this. 66.666% isn't an
unreasonable bar. If you can't get 2 out of 3 people to think your
idea makes sense, then it might need work.
-Sara
I'd like to bring https://wiki.php.net/rfc/abolish-narrow-margins to vote
in the very near future ...We discussed it a year ago, and discussion died down to nothing (possibly
because it was sidetracked); If there are no objections I'll bring it to
vote in the coming days ...
Since you brought it up ...
"The current political climate of Earth
It's probably less "Earth" and more "Western civilization."
votes that are won by narrow margins build resentment among voters
Well, certainly among some. I have to wonder if this is a reference to the author's favored political outcomes being thwarted.
can lead to instability in the ecosphere
The "ecosphere" of Earth? That's an interesting assertion. I wonder if it's true.
and could be considered harmful to democracy.
There's a long list of things that "could be considered harmful to democracy."
In any case, are we turning this list into a political forum? Because I for one can do without it here. I find it in plenty of other places.
I don't have any more to say on that aspect of this topic right now, unless and until someone else here sees fit to continue it -- in which case, I'll be happy to respond.
--
Paul M. Jones
pmjones@pmjones.io
http://paul-m-jones.com
Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp
Solving the N+1 Problem in PHP
https://leanpub.com/sn1php
--
Paul M. Jones
pmjones@pmjones.io
http://paul-m-jones.com
Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp
Solving the N+1 Problem in PHP
https://leanpub.com/sn1php
Hi!
We discussed it a year ago, and discussion died down to nothing (possibly
because it was sidetracked); If there are no objections I'll bring it to
vote in the coming days ...
I tend to agree with the sentiment, but not 100%. I think there are two
kinds of changes - one kind is more fundamental than the other. I.e., if
we add a major feature to the language (like strict type checks, for
example) it is going to have major influence on the language and
virtually everybody using it. You can't just ignore it. This also goes
to changes which alter ways that the syntax works, etc. which have
potential to break existing code (even if it's bad code, still).
Then there are more "neutral" changes - like adding an utility function
or an option to a function. PHP has a lot of "syntax sugar" functions
and sometimes even "kitchen sink" functions - ones that most people
don't use but some do. Having one more would not be that big of a deal -
that's where, unlike the above, "what you don't use doesn't hurt you" is
true.
You probably have guessed already what I am getting at - the second kind
is probably OK to have 50%+1, since people that don't need this
option/function can vote no but still we can have it if more people do.
The counter-argument could be that people that don't need it can just
avoid voting, but then we don't have clear boundary between "I don't
think it's useful for enough people to add it" and "I am on vacation and
haven't bothered to even have an opinion".
That said, I'd love to see how many of the accepted RFCs we have now
were actually accepted by margin between 50%+1 and 2/3 and what they
are, if the number is very low maybe it's irrelevant. Unfortunately I
don't have time to do it myself soon, but it would be super-awesome if
somebody did.
P.S. The question of quorum is interesting to explore, though I am not
sure how we figure out the numbers.
Stas Malyshev
smalyshev@gmail.com
Hi!
We discussed it a year ago, and discussion died down to nothing (possibly
because it was sidetracked); If there are no objections I'll bring it to
vote in the coming days ...I tend to agree with the sentiment, but not 100%. I think there are two
kinds of changes - one kind is more fundamental than the other. I.e., if
we add a major feature to the language (like strict type checks, for
example) it is going to have major influence on the language and
virtually everybody using it. You can't just ignore it. This also goes
to changes which alter ways that the syntax works, etc. which have
potential to break existing code (even if it's bad code, still).Then there are more "neutral" changes - like adding an utility function
or an option to a function. PHP has a lot of "syntax sugar" functions
and sometimes even "kitchen sink" functions - ones that most people
don't use but some do. Having one more would not be that big of a deal -
that's where, unlike the above, "what you don't use doesn't hurt you" is
true.You probably have guessed already what I am getting at - the second kind
is probably OK to have 50%+1, since people that don't need this
option/function can vote no but still we can have it if more people do.
The counter-argument could be that people that don't need it can just
avoid voting, but then we don't have clear boundary between "I don't
think it's useful for enough people to add it" and "I am on vacation and
haven't bothered to even have an opinion".
If it's a utility function and somehow ~49% of voters oppose it...
think about that. It's 49% objectionable! I don't think that should
pass, not even for a utility function people.
That said, I'd love to see how many of the accepted RFCs we have now
were actually accepted by margin between 50%+1 and 2/3 and what they
are, if the number is very low maybe it's irrelevant. Unfortunately I
don't have time to do it myself soon, but it would be super-awesome if
somebody did.
I did this analysis in the past. There are very few RFCs that passed
in this window between 50%+1 and 2/3, but there are a few. The
array_key_first/last RFC is on track to pass in this region.
P.S. The question of quorum is interesting to explore, though I am not
sure how we figure out the numbers.
Am 11.07.2018 um 20:18 schrieb Stanislav Malyshev:
That said, I'd love to see how many of the accepted RFCs we have now
were actually accepted by margin between 50%+1 and 2/3 and what they
are, if the number is very low maybe it's irrelevant. Unfortunately I
don't have time to do it myself soon, but it would be super-awesome if
somebody did.
See https://www.mail-archive.com/internals@lists.php.net/msg82852.html
and particularly <bit.ly/php7rfcs>;.
--
Christoph M. Becker
and particularly <bit.ly/php7rfcs>;.
Interesting, better than I'd thought actually.
It's odd that the 64bit stuff was the one that was < 2/3rds. iirc the
only honestly contentious thing about that was the potential to break
existing extensions (which php-ng pretty did anyway). I know there
was concern about those two having to merge, and I know I fell on the
side of the one that was developed more publicly, but it still seems
like a no-brainer to me.
I don't remember the specifics about integer semantics (which fell
precisely on 2/3 and thus would have failed the +1 check), but again
I'll offer than perhaps both needed more discussion, and maybe
shouldn't have passed. shrug
-Sara
Hey Sara,
Sara Golemon wrote:
I don't remember the specifics about integer semantics (which fell
precisely on 2/3 and thus would have failed the +1 check), but again
I'll offer than perhaps both needed more discussion, and maybe
shouldn't have passed. shrug-Sara
2/3+1 is silly, though. 2/3 already means there's twice as many agreeing
as disagreeing, having +1 doesn't serve the tie-breaking function there
that it does for 50%+1. But that was indeed a knife-edge RFC, it was
actually saved by someone chosing to vote Yes at the last minute.
--
Andrea Faulds
https://ajf.me/
2/3+1 is silly, though. 2/3 already means there's twice as many agreeing as
disagreeing, having +1 doesn't serve the tie-breaking function there that it
does for 50%+1. But that was indeed a knife-edge RFC, it was actually saved
by someone chosing to vote Yes at the last minute.
I can buy that argument, but since there IS room to disagree, then
such should be spelled out clearly in the voting update RFC. Let's
decide and not leave it to subjective interpretation.
-Sara
Zeev,
I think our voting rules are in need of a much thorough review than just
pushing the limit to 2/3 - which also IMHO doesn't tackle the difference
scenarios that exist out there.
Agree, they need reform, but rather than trying to discuss and pass a
monolithic RFC that tries to solve all problems, I chose (a year ago) to
start here; Simply raising the bar simplifies the rules we currently have
and so simplifies their reform (in detail and process).
I'm not following your logic for further delaying voting on this RFC, in
fact I don't see any logic, just an assertion ;)
Cheers
Joe
2/3+1 is silly, though. 2/3 already means there's twice as many agreeing
as
disagreeing, having +1 doesn't serve the tie-breaking function there
that it
does for 50%+1. But that was indeed a knife-edge RFC, it was actually
saved
by someone chosing to vote Yes at the last minute.I can buy that argument, but since there IS room to disagree, then
such should be spelled out clearly in the voting update RFC. Let's
decide and not leave it to subjective interpretation.-Sara
Zeev,
I think our voting rules are in need of a much thorough review than just
pushing the limit to 2/3 - which also IMHO doesn't tackle the difference
scenarios that exist out there.Agree, they need reform, but rather than trying to discuss and pass a
monolithic RFC that tries to solve all problems, I chose (a year ago) to
start here; Simply raising the bar simplifies the rules we currently have
and so simplifies their reform (in detail and process).
I think the problem is that there are cases where a 2/3 vote (or a vote at
all) doesn't make sense. True, we didn't have too many of those in the
past - but as we reform, I think it's important to take note of them.
Things which don't effect the language, but are more of a question of
preference - e.g., the decision to name phpng as PHP 6 vs PHP 7 - or for
that matter, deciding about a different release cadence. It's one thing to
add a language construct, to change the behavior of a function or to
add/remove an extension - this bubbles into people's code and we'd have to
live with this decision and its implications even in a decade's time -
while we can change our release cadence 3 times in between (if we wanted
to), and obviously whether phpng ended up being called PHP 6 or PHP 7 had
no technical meaning, only a 'marketing' one. Then there are also
implementation decisions - where things in the past have been a bit unclear
- and I think it's needed to clarify that such decisions (including
substantial refactoring, as long as there's no negative end-user impact)
should not require voting, but are up for the folks actually maintaining
that particular piece of code to decide.
So while I think non 2/3 votes would be uncommon, I do think we need to
have provisions for them - and voting to make everything 2/3 right now
without discussing the wider scope is wrong IMHO.
Also while generally I very much agree with the 'agile' sentiment of fixing
things gradually instead of in one monolithic step - our voting rules are
so lacking that it feels like putting a band aid on a gunshot wound...
By the way, I still think there's a lot of work that still needs to happen
on my proposal - perhaps factor in quorums, how votes relate to deadlines -
we can probably learn quite a bit from our experience including in recent
weeks - but I think it's mature enough for others to comment on it, and I
would be very happy for others to join me in drafting it.
I'm not following your logic for further delaying voting on this RFC, in
fact I don't see any logic, just an assertion ;)
Here's one example of our lacking rules (IMHO of course) - this has been in
the attic for just under a year, and now we're considering to just move it
to a vote within days. I don't think that should be possible :) The way I
see it, the voting period has to happen immediately after the mandatory
discussion period - and in a very predictable manner . If an RFC goes
dormant, there should be a new discussion period prior to voting.
On my logic for not dealing with it right now, it's twofold:
- There's too much activity going on around last minute 7.3 RFCs for many
people to have the bandwidth to discuss it in a serious manner. - It seems wrong to change the rules mid-flight in a way which might
affect the current 7.3 votes which are already under way (not that I think
it will affect most of them - but it still seems wrong).
Sorry for not actually mentioning that previously :)
Zeev
I think the problem is that there are cases where a 2/3 vote (or a vote at
all) doesn't make sense. True, we didn't have too many of those in the
past - but as we reform, I think it's important to take note of them.
Things which don't effect the language, but are more of a question of
preference - e.g., the decision to name phpng as PHP 6 vs PHP 7 - or for
that matter, deciding about a different release cadence. It's one thing to
add a language construct, to change the behavior of a function or to
add/remove an extension - this bubbles into people's code and we'd have to
live with this decision and its implications even in a decade's time -
while we can change our release cadence 3 times in between (if we wanted
to), and obviously whether phpng ended up being called PHP 6 or PHP 7 had
no technical meaning, only a 'marketing' one. Then there are also
implementation decisions - where things in the past have been a bit unclear
- and I think it's needed to clarify that such decisions (including
substantial refactoring, as long as there's no negative end-user impact)
should not require voting, but are up for the folks actually maintaining
that particular piece of code to decide.
So while I think non 2/3 votes would be uncommon, I do think we need to
have provisions for them - and voting to make everything 2/3 right now
without discussing the wider scope is wrong IMHO.
Perhaps the most important factor is whether we actually change
something (e.g. new feature, deprecation, voting process), or whether we
merely have to make a decision about something that is not covered by
existing rules (e.g. next version 7.4 or 8). Of course, that's still
somewhat vague, but might be a good rule of thumb.
Here's one example of our lacking rules (IMHO of course) - this has been in
the attic for just under a year, and now we're considering to just move it
to a vote within days. I don't think that should be possible :) The way I
see it, the voting period has to happen immediately after the mandatory
discussion period - and in a very predictable manner . If an RFC goes
dormant, there should be a new discussion period prior to voting.
ACK. In my opinion, we would profit from a more structured and
automated RFC solution. As it is now, the administration of the RFCs
need too much manual intervention. For instance, marking an obviously
inactive RFC as such, requires to manually edit the RFC overview, and
to modify the status on the actual RFC. Also it would be benefitial, if
votes closed automatically on the scheduled end date. Or regarding this
very case: if there are no further replies to the RFC discussion thread
for a week or so, the RFC should automatically moved to “inactive”, if
it hasn't been moved to voting in the meantime.
--
Christoph M. Becker
Hi!
Things which don't effect the language, but are more of a question of
preference - e.g., the decision to name phpng as PHP 6 vs PHP 7 - or for
that matter, deciding about a different release cadence. It's one thing to
That's one of the places where 50% or plurality vote would be
appropriate - when we have binary (or n-ary) choice for some decision
that has to be taken. We don't want to end up in an absurd situation of
not choosing any name or any release date because none of the options
has 2/3. So in this situation, I think we go with the majority or
plurality (in case of multiple options) vote.
--
Stas Malyshev
smalyshev@gmail.com
Hi!
Things which don't effect the language, but are more of a question of
preference - e.g., the decision to name phpng as PHP 6 vs PHP 7 - or for
that matter, deciding about a different release cadence. It's one thing toThat's one of the places where 50% or plurality vote would be
appropriate - when we have binary (or n-ary) choice for some decision
that has to be taken. We don't want to end up in an absurd situation of
not choosing any name or any release date because none of the options
has 2/3. So in this situation, I think we go with the majority or
plurality (in case of multiple options) vote.--
Stas Malyshev
smalyshev@gmail.com--
I think for n-ary votes we need a different system. Only being able to
cast one vote with winner takes all has a lot of downsides.
I'm not sure what distinguishes binary votes that only need >50%. I
don't think as simple as whether or not there is code involved; for
example changing our RFC processes and such should require more
agreement than that.
Hi!
See https://www.mail-archive.com/internals@lists.php.net/msg82852.html
and particularly <bit.ly/php7rfcs>;.
Ah yes, thanks, I thought I remembered something like that. It's a bit
old but still good. Looks like the number of RFCs that would suffer from
move to 2/3 is very low, thus I think it's a good idea.
--
Stas Malyshev
smalyshev@gmail.com
-----Original Message-----
From: Joe Watkins [mailto:krakjoe@php.net]
Sent: Wednesday, July 11, 2018 7:41 PM
To: PHP internals internals@lists.php.net
Subject: [PHP-DEV] [RFC] abolish narrow marginsAfternoon internals,
I'd like to bring https://wiki.php.net/rfc/abolish-narrow-margins to vote in the
very near future ...We discussed it a year ago, and discussion died down to nothing (possibly
because it was sidetracked); If there are no objections I'll bring it to vote in the
coming days ...
Last year I worked on a bigger rework of our voting rules that tackles this, among other topics - given the many deficiencies of the original Voting RFC (which was hastily drafted, approved with virtually zero discussion, and yet has been considered as some sort of constitution ever since). I admit I didn't have the mental strength to bring it up for discussion but I think our voting rules are in need of a much thorough review than just pushing the limit to 2/3 - which also IMHO doesn't tackle the difference scenarios that exist out there.
I think it would make sense to start discussing that (as well as the abolish-narrow-margins RFC along with it if you prefer to put it to a vote) as soon as we're done with the 7.3 contents, and in preparation for 7.4/8.0 (i.e. around the September/October timeframe). We could of course start discussing it sooner, but at least I don't think it makes sense to vote on either of these right now.
Zeev