As I said numerous times in the past, I'm a firm believer that
controversial RFCs (ones that generate a lot of votes with a substantial
number of opposers) should not pass. I think this is important when
features - but it's actually a lot more important with deprecations.
there's substantial doubt whether a deprecation should go through or
there should be no doubt at all - it shouldn't. This is one of the
clearest cases if not the clearest one we've had to date.
This IMHO applies to the deprecation vote which includes the default
From my POV it applies to all deprecations, although obviously taking out
something that's been a basic building block for the last 20+ years is
probably more of an issue than some 3rd party utility function.
I think this just boils down to what is an acceptable majority, if 2/3 is
not enough then 3/4
but this is another debate altogether.
I've argued in the past that it would make sense to require a 9/10 majority
for RFCs. Very few RFCs that passed - only cleared a 2/3 majority.
Usually (in the vast majority of cases), it either clears a nearly
unanimous vote - or it doesn't even come close to 2/3.
RFCs that have a high number of votes (i.e., that people feel strongly
about), and barely pass the 2/3 mark - are controversial and saw division.
Yes, it means that out of the (almost random) group of people who are
currently enabled to vote by our (flawed) voting system - there are 2x more
people that want the RFC to pass vs. not, but at the same time, it also
means that there's a great number of folks who think that it's a Really Bad
This is even stronger with deprecations, where the biggest downside is
compatibility breakage. Unlike new features, where you simply have to
illustrate that the feature is a good idea - here, you don't only have to
demonstrate that the feature you propose to deprecate is a bad idea - but
rather, that it's so bad - that we're better off removing it and inducing
compatibility breakage on our huge, several million strong userbase. If a
very substantial number of folks thinks otherwise, it should make others
pause - even if they dislike this feature and think it's bad, and consider
whether it's really so horrid that it must be removed. Unfortunately, this
line of thought doesn't appear to be happening - and it seems that many
vote in favor of deprecation based on whether or not they like the feature.
It's absolutely fine to dislike short tags. It's absolutely fine to
believe it shouldn't have been introduced. But the gap between that, and
thinking it's fine to remove it - is very, very big.
This was indeed the intention of the voting structure as I wanted to have a
vote to get see
if people were filling to remove it with PHP 8 or leave it longer in the
However looking at how some people voted against the deprecation notice
but for the removal
the only meaningfull conclusion I can come up with is that the change of
the default value is
It's very difficult to deduce what people were thinking because the
questions were not properly structured. Some people probably only voted on
one vote and not the other, thinking the other is irrelevant. It's fairly
difficult to guess how it influenced the final tally, all the more reason
to properly restructure the vote and restart it.
I mean I don't see how we are in unchartered territory, the vote passed,
with not a huge supra majority but it still passed.
We're in unchartered territory not from a process perspective, but in
terms of the number of core devs who think it's a really bad idea and the
fact we're rediculously close to the minimum threshold - for something that
should really happen with consensus.
I can see this but is it really unheard of?
It's not unheard of, but it's also extremely uncommon. And in my opinion,
should be avoided - especially in cases like this - where the value
associated with the RFC isn't overwhelming. In the grand scheme of things,
removing short tags isn't going to move the needle for the popularity of
PHP, definitely not in a positive direction anyway. It has mostly the
potential to make certain folks feel better about the syntactical purity of
the language - while at the same time making the upgrade process more
difficult - in a world where one of our biggest challenges is that people
don't upgrade frequently enough.
Because what prevent me from then re-openning the vote again if the vote
Nothing really, other than common courtesy.
I was even hoping that the RFC will be withdrawn given the number of nays
from core devs, but that's of course something that is up to you.
In all honesty I didn't check who votes for what as IMHO everybody is
to their opinion.
Of course everyone is entitled to an opinion, but not everyone is entitled
to a vote. As I've said numerous times over the years, our voting system
is flawed and provides voting privileges to folks who are not supposed to
have voting privleges per the Voting RFC, simply because it was the
simplest way to implement it at the time. It created a situation that has
no parallels in the Open Source world, at least none I'm aware of. Open
Source projects (non-commercial ones at least) tend to always be based on
meritocracy. PHP is pretty much the only high profile project where
someone who spend years of their time working on creating the project, has
the same weight as someone who submitted a couple of patches or even didn't
submit any patches at all. And no, it was never intentional - it's a flaw
of the voting system that is only getting bigger and bigger as years go by
- where the number of core devs stays roughly the same, but the number of
folks with voting access grows larger and larger. And no, it's not that I
think we 'saw the light' that all other OS projects don't see. Fixing it
is simply a very challenging task that nobody has been up for thus far.
The problem I have with putting this again to a vote is that it feels
revote until the
outcomes is convenient to me. And going with this logic I feel I could say
redo a vote to deprecate the var keywword as the last vote was 3 years ago
and maybe opinions have changed. It just end in more resentment IMHO.
Ther'e s fundametal difference between votes that were already implemented
and went out, and something where the vote just ended a couple of days
ago. Even more so given the fact that there were issues with the way the
voting options were laid out that made them inconsistent with the Voting
RFC and our rules, and might have influenced how people voted (in both
directions). That alone should be sufficient grounds to redo the vote and
do it properly.