Morning internals,
There is confusion among the community, and contained in the documented
history of PHP on the wider internet.
The Wikipedia states that PHP is developed by the PHP Group, in saying this
it is (must be) referring to internals as a whole, but our own
documentation names members of the group - who aren't even around mostly.
I think we need to clarify what exactly is the purpose of the PHP Group
today, does anyone want to attempt to do that ?
Whatever it's purpose, if it has one, we need to make clear at this time
that there are no vetos: As Rasmus clarified, PHP is driven by the people
who write PHP: No member of any group or company, historical or otherwise,
has any veto powers, they cannot, and they must not behave as if they do.
I would like to update the introduction to the Voting RFC:
The development of PHP is community driven by the RFC process described in
this document. Anyone may initiate an RFC for any subject. At the end of
the RFC process a vote is held among PHP developers to determine if the
proposal is to be accepted.
Should a proposal be accepted, the developers of PHP are committed to
making the change.
In some circumstances, merging an implementation into the source code of
PHP may be delayed because of shortcomings in that implementation. In these
cases, resolution of these shortcomings is the responsibility of the
proposer.
Should a proposal be accepted without an implementation, it is the
responsibility of the proposer to provide one.
Does anyone object to any of those words ?
Do we need to vote on changing the introduction (I'm happy to start an rfc
for this, if necessary) ?
Cheers
Joe
The Wikipedia states that PHP is developed by the PHP Group, in saying this
it is (must be) referring to internals as a whole, but our own
documentation names members of the group - who aren't even around mostly.I think we need to clarify what exactly is the purpose of the PHP Group
today, does anyone want to attempt to do that ?
Joe, I applaud this move.
As a non-American and so used to a different legal system, I have a further
point I would like clarified: the PHP website and PHP license say
"Copyright the PHP Group" (https://www.php.net/copyright.php,
https://www.php.net/license/3_01.txt).
How can an undefined group have copyright vested in it? And more
importantly, how would it defend or deal with a copyright infringement if
"The PHP Group" is not a recognised group or legal entity?
Peter
On Sun, Sep 15, 2019 at 2:37 PM Peter Bowyer phpmailinglists@gmail.com
wrote:
The Wikipedia states that PHP is developed by the PHP Group, in saying
this
it is (must be) referring to internals as a whole, but our own
documentation names members of the group - who aren't even around mostly.I think we need to clarify what exactly is the purpose of the PHP Group
today, does anyone want to attempt to do that ?Joe, I applaud this move.
As a non-American and so used to a different legal system, I have a further
point I would like clarified: the PHP website and PHP license say
"Copyright the PHP Group" (https://www.php.net/copyright.php,
https://www.php.net/license/3_01.txt).How can an undefined group have copyright vested in it?
It's very much well-defined. And certainly not by Wikipedia, but in the
PHP source code and the php.net website itself. Right at the top of the
Credit page:
https://www.php.net/credits.php
And more
importantly, how would it defend or deal with a copyright infringement if
"The PHP Group" is not a recognised group or legal entity?
Thankfully, copyright infringements are practically irrelevant as far as
the PHP license is concerned. License violations are also pretty much
irrelevant, with the only practical exception being someone breaking the
clause that requires them not to use the name 'PHP' to promote a derivative
product. But we've been able to deal with this gracefully for the past ~20
years, and I don't see a reason that should change.
To the suggested proposal - it's quite obvious that you can't use a
mechanism to widen its own scope. Changing the Voting RFC (either
unilaterally or by using the Voting RFC itself) to extend its jurisdiction
is meaningless. It was never, ever designed to be a mechanism to radically
alter the language (which nobody even considered as an option at the time
of its introduction) - but as a way to extend it. There are several
references in the text - both of the Voting RFC itself, the RFC template
and the RFC howto that make the scope of this mechanism quite clear.
Note that I'm not at all advocating that we defer deprecation/radical
changes to Group. That's impractical and more importantly - makes no
sense. But so is using the same threshold for adding a feature and
removing it - that too makes absolutely no sense at all. The negative
end-user impact from taking away a feature that they've grown to rely on is
virtually always far greater than adding it in the first place. In 20+
years of the project, there were 3 proactive major compatibility breakages
that we decided to go for - namely, register_globals, magic_quotes and
safe_mode. The first two had super simple one liner workarounds, and were
disabled by default for many years before they were deprecated and
subsequently removed. The 3rd was so inherently unsafe and complex to
maintain that we decided that the price of removing it was worth the impact
- which was limited almost exclusively to shared hosters (and there were
much more reliable alternatives emerging at the time). We didn't have a
voting mechanism back then, these decisions passed in near-consensus (not
66/33, but an overwhelming support and very little opposition, IIRC a lot
closer to 10 to 1 vs. 2/3).
We a new mechanism for deprecations/radical changes - i.e., things that
break existing code (as opposed to make new code possible). It can reuse
much of the process of the Voting RFC, but the threshold has to correlate
to the expect breakage impact (and we need to be able to measure that in a
reasonable way). Simple things with limited impact can stick with 2/3,
which is still too low but has become a standard. Things with far-reaching
impact should have a much higher, near-consensus bar. Yes, it means that
proposals with a far-reaching effect on end users will need to be almost
unanimously agreed upon before they clear, much like they did in the past
when we've made similar decisions. They'll have to have a super convincing
case and not one that's deemed controversial by a sizable number of
voters. Which means they'll be uncommon, and when they do take place -
it'll be for very good reasons.
Zeev
We a new mechanism for deprecations/radical changes
The current maintainers are not bound by choices made by other people,
years ago.
No-one wants to break stuff just for the sake of it, but we are free
to correct mistakes that were made in the past, and also revisit
decisions that were correct at the time but are no longer appropriate
given current circumstances.
I ask you again, please stop trying to impose your will on how PHP is
maintained.
It is not appropriate.
If it continues, we are going to have to look at bringing in a code of
conduct to prevent this disruptive behaviour from being such a
negative effect on other people.
cheers
Dan
Ack
How can an undefined group have copyright vested in it?
It's very much well-defined. And certainly not by Wikipedia, but in the
PHP source code and the php.net website itself. Right at the top of the
Credit page:
https://www.php.net/credits.php
Respectfully, this is a list of people who are identified as part of the
PHP Group.
My understanding is copyright has to be vested in individuals or
legally-recognised entities. The PHP Group is neither of those. The
wording "Copyright The PHP Group" is different to saying "Copyright the
individual contributors (hereafter referred to as "The PHP Group").
This led me to check that contributors to PHP do not have to assign
copyright to the PHP Group (I checked
https://github.com/php/php-src/blob/master/CONTRIBUTING.md
https://github.com/php/php-src/blob/master/CONTRIBUTING.md#copyright-and-license-headers).
So what are the PHP Group holding copyright over?
As ever I welcome being set right if this is inaccurate.
And more
importantly, how would it defend or deal with a copyright infringement if
"The PHP Group" is not a recognised group or legal entity?Thankfully, copyright infringements are practically irrelevant as far as
the PHP license is concerned. License violations are also pretty much
irrelevant, with the only practical exception being someone breaking the
clause that requires them not to use the name 'PHP' to promote a derivative
product.
I'm pleased that has been the case. Long may it continue.
Peter
Hi Pierre,
The RFC process defines a veto and could be applied when needed.
Can you show me where that is defined please ?
Cheers
Joe
On Mon, 16 Sep 2019 at 10:36, Peter Bowyer phpmailinglists@gmail.com
wrote:
How can an undefined group have copyright vested in it?
It's very much well-defined. And certainly not by Wikipedia, but in the
PHP source code and the php.net website itself. Right at the top of the
Credit page:
https://www.php.net/credits.phpRespectfully, this is a list of people who are identified as part of the
PHP Group.My understanding is copyright has to be vested in individuals or
legally-recognised entities. The PHP Group is neither of those. The
wording "Copyright The PHP Group" is different to saying "Copyright the
individual contributors (hereafter referred to as "The PHP Group").This led me to check that contributors to PHP do not have to assign
copyright to the PHP Group (I checked
https://github.com/php/php-src/blob/master/CONTRIBUTING.md
<
https://github.com/php/php-src/blob/master/CONTRIBUTING.md#copyright-and-license-headers).
So what are the PHP Group holding copyright over?As ever I welcome being set right if this is inaccurate.
And more
importantly, how would it defend or deal with a copyright infringement
if
"The PHP Group" is not a recognised group or legal entity?Thankfully, copyright infringements are practically irrelevant as far as
the PHP license is concerned. License violations are also pretty much
irrelevant, with the only practical exception being someone breaking the
clause that requires them not to use the name 'PHP' to promote a
derivative
product.I'm pleased that has been the case. Long may it continue.
Peter
Hi Pierre,
The RFC process defines a veto and could be applied when needed.
Can you show me where that is defined please ?
In the current version, there is no mention of veto, which surprises
me. It was definitively something that was in it. Zeev, Andi, other
and myself discussed that part to hell back then. I cannot dig the
revisions (the wiki box is extremely slow right now). If it was not,
then we failed in the very first version as it was definitively agreed
to have that veto (tbc :).
Best,
Hi Pierre,
The RFC process defines a veto and could be applied when needed.
Can you show me where that is defined please ?
In the current version, there is no mention of veto, which surprises
me. It was definitively something that was in it. Zeev, Andi, other
and myself discussed that part to hell back then. I cannot dig the
revisions (the wiki box is extremely slow right now). If it was not,
then we failed in the very first version as it was definitively agreed
to have that veto (tbc :).
And 500, so I give up digging :)
By the way, the Group could do it anyway given the license and co.
However, again, the group never did it and will most likely never do
it anyway.
The key points in my reply were other, which you may consider to
discuss rather than something that will never happen :)
Best,
Pierre
@pierrejoye | http://www.libgd.org
Pierre,
I repeat, there are no vetos, for anyone.
Cheers
Joe
Hi Pierre,
The RFC process defines a veto and could be applied when needed.
Can you show me where that is defined please ?
In the current version, there is no mention of veto, which surprises
me. It was definitively something that was in it. Zeev, Andi, other
and myself discussed that part to hell back then. I cannot dig the
revisions (the wiki box is extremely slow right now). If it was not,
then we failed in the very first version as it was definitively agreed
to have that veto (tbc :).And 500, so I give up digging :)
By the way, the Group could do it anyway given the license and co.
However, again, the group never did it and will most likely never do
it anyway.The key points in my reply were other, which you may consider to
discuss rather than something that will never happen :)Best,
Pierre
@pierrejoye | http://www.libgd.org
Hi Joe,
Pierre,
I repeat, there are no vetos, for anyone.
Sorry to factually disagree here. Whether I or you like it is not
relevant here.
By the way, can we focus on more important points, I do think that
will bring the whole thing a bit further up the hill.
Best,
Pierre
For there to be a veto, of the kind that anyone can actually use, it must
be established somewhere.
What you are talking about simply does not exist, you can assert all you
like that "the group" can do whatever they like, but they have no means to
do so that any other contributor needs to recognize.
I'm not going to discuss the legalities of what it means that the group
hold copyright, you and I are not lawyers and that conversation is
meaningless.
Cheers
Joe
Hi Joe,
Pierre,
I repeat, there are no vetos, for anyone.
Sorry to factually disagree here. Whether I or you like it is not
relevant here.By the way, can we focus on more important points, I do think that
will bring the whole thing a bit further up the hill.Best,
Pierre
Hi!
For there to be a veto, of the kind that anyone can actually use, it must
be established somewhere.
And that's what I am concerned about. Once we start assuming the RFC
process is not for solving technical questions for everything, we get
into this kind of rule lawyering and nitpicking into the texts which
never were intended to be able to serve as something that can work while
being base for rule-lawyering and nitpicking. It's not a constitution
(not that lawyers don't find all kinds of things all the time there that
were never written there either) and the fact that voting RFC or
whatever document is on wiki now does or does not have certain words in
there does not have any sacred meaning, because it wasn't even meant for
that. These are utilitarian documents which were written for specific
purposes, and should be understood within that context. And if they do
not match what we want to do now, they can and should be changed.
--
Stas Malyshev
smalyshev@gmail.com
Hi!
For there to be a veto, of the kind that anyone can actually use, it must
be established somewhere.And that's what I am concerned about. Once we start assuming the RFC
process is not for solving technical questions for everything, we get
into this kind of rule lawyering and nitpicking into the texts which
never were intended to be able to serve as something that can work while
being base for rule-lawyering and nitpicking. It's not a constitution
(not that lawyers don't find all kinds of things all the time there that
were never written there either) and the fact that voting RFC or
whatever document is on wiki now does or does not have certain words in
there does not have any sacred meaning, because it wasn't even meant for
that. These are utilitarian documents which were written for specific
purposes, and should be understood within that context. And if they do
not match what we want to do now, they can and should be changed.--
Stas Malyshev
smalyshev@gmail.com
Simple question for those that keep arguing that the RFC process is only applicable to a certain subset of issues:
OK, so what's the alternative?
If we wanted to make a structural or governance change to PHP, what is the process?
If we really did feel there was a reason to make a fundamental change to the language (whatever that means), what is the process?
If we wanted to change the RFC process, what is the process?
If we don't have those, and want to set them up, what is the process for defining the process?
--Larry Garfield
On Tue, Sep 17, 2019 at 3:32 PM Larry Garfield larry@garfieldtech.com
wrote:
Simple question for those that keep arguing that the RFC process is only
applicable to a certain subset of issues:OK, so what's the alternative?
If we wanted to make a structural or governance change to PHP, what is the
process?
If we really did feel there was a reason to make a fundamental change to
the language (whatever that means), what is the process?
If we wanted to change the RFC process, what is the process?
If we don't have those, and want to set them up, what is the process for
defining the process?
For the first and last one (which are kind of the same) - the answer is
simply the (informal) process we had before the RFC process was enacted.
That effectively meant consensus based decision making.
Since we have a lot more people today, we can and probably should reuse the
voting mechanism, and a pass would have to look along the lines of this:
https://web.archive.org/web/20120527111218/https://wiki.php.net/rfc/voting/vote
or
https://wiki.php.net/rfc/abolish-short-votes
If you look at all the 'Process and Policy' RFCs we've voted on, other than
a couple that are miscategorized technical RFCs - they virtually all
cleared a 15 to 1 bar, most of them well above that. When changing the
rules - or extending the scope of the RFC process to handle things it never
has before, this is what it takes. We haven't implemented any rules that
bind everyone without that level of widespread agreement to this date.
Consensus based decisions would work for the 3rd one as well and would
probably be the simplest to enforce. It may be that for RFCs that place
new limits on it (like the recent Abolish votes) a 2/3 bar would suffice -
although I think it's healthy for everyone that the ratio that was reached
was more along the lines of 20 to 1 than 2 to 1, in terms of everyone
accepting the validity of the policy change (including the fingerful who
voted against). But since determining whether a policy RFC falls in that
category or not can in itself be challenging, having a single, clear high
bar for introducing both changes to the Voting RFC, as well new policy
rules, would probably be the simplest and probably healthiest outcome.
Regarding the 2nd (fundamental / high impact changes) - the solution here
too would be consensus based decision making. That's the bar we cleared in
previous major changes - the deprecation of register_globals, magic_quotes
and safe_mode. Now, I think Nikita does have a point that defining what
constitutes a 'high impact' break vs. one that isn't very easy - especially
in a formal manner. So it may make sense to have a single bar for all
compatibility breaking changes, instead of a separate one for high impact
ones and low impact ones. The solution might be to simply gauge the level
of caring through the number of voters who took the time to vote. For
instance, a change proposal that garnered 10 votes, 7 to 3, is probably not
a high-impact one and it may be reasonable to accept it even if it only
cleared a 2 to 1 ratio. A change proposal that garners 50 votes and is 35
in favor and 15 against (exactly the same ratio, but with a lot more
voters) - is most probably a high impact one, and should clear a much
higher consensus-level bar. In the meantime, formality aside, it's easy
enough to 'know it when you see it'. I don't think anybody contends that
changing our undefined variable behavior or deprecating short tags are
high-impact breaks - in terms of the lines of code in the combined
universal PHP code base that would have to be changed as a result.
Other than the higher bar - I think such proposals should be required (or
at the very least encouraged) to do a better impact analysis regardless.
They should be tested on a set of apps (one that will attempt to represent
the PHP codebase at large, not just the cutting-edge framework
development), and the results should be available as a part of the RFC.
Even if we can't formally compute from that data whether it constitutes
high-impact or not, having that data as a part of the RFC will likely help
voters determine their opinion on it - first at the level of whether they
care or not, and secondly - whether they're in favor or not. This will, in
turn, effect voter turnout - and help determine whether this is indeed a
major change or not.
In addition, I don't think we should be grouping any deprecations together
into a single vote - unless that's absolutely required from a technical
standpoint (i.e. doing one without the other would lead to an
inconsistency). With the recent engine errors reclassification RFC,
initially - the deprecation of default values for uninitialized variables
wasn't even viewed as a very big deal and was grouped with the rest. It's
true that this quickly became apparent and Nikita separated it after a
couple of days - but I think that should be a requirement, and not up to
the RFC author. I also agree with Christian - the fact that this
deprecation was by far the biggest one - basically distracted everyone
(myself included) from discussing the smaller ones. This means that while
there are probably some issues with some of the other, smaller changes -
the fact they're lumped together with others which are harmless, and the
fact there was practically no discussion over any of them - means it's all
too easy to vote in favor of changing the entire group. Combined with no
impact analysis being available for each proposal - it's very likely that
there's 'herd mentality' happening there. Putting each in a separate vote
would have likely not thoroughly solved this, but it would have probably
been a good first step, allowing more granular choice. I think that this
particular change (requiring separate votes for each change) can be done
relatively easily within our existing framework - similar to the Abolish
RFCs, if there's widespread agreement. In the context of Ben's email from
a few weeks ago, I'll defer to someone else to propose it if they think it
makes sense.
Zeev
I agree with pretty much everything Zeev has said. I've added a few
additional thoughts
On Tue, Sep 17, 2019 at 3:32 PM Larry Garfield larry@garfieldtech.com
wrote:Simple question for those that keep arguing that the RFC process is only
applicable to a certain subset of issues:OK, so what's the alternative?
If we wanted to make a structural or governance change to PHP, what is
the
process?
If we really did feel there was a reason to make a fundamental change to
the language (whatever that means), what is the process?
If we wanted to change the RFC process, what is the process?
If we don't have those, and want to set them up, what is the process for
defining the process?For the first and last one (which are kind of the same) - the answer is
simply the (informal) process we had before the RFC process was enacted.
That effectively meant consensus based decision making.
Since we have a lot more people today, we can and probably should reuse the
voting mechanism, and a pass would have to look along the lines of this:https://web.archive.org/web/20120527111218/https://wiki.php.net/rfc/voting/vote
or
https://wiki.php.net/rfc/abolish-short-votesIf you look at all the 'Process and Policy' RFCs we've voted on, other than
a couple that are miscategorized technical RFCs - they virtually all
cleared a 15 to 1 bar, most of them well above that. When changing the
rules - or extending the scope of the RFC process to handle things it never
has before, this is what it takes. We haven't implemented any rules that
bind everyone without that level of widespread agreement to this date.Consensus based decisions would work for the 3rd one as well and would
probably be the simplest to enforce. It may be that for RFCs that place
new limits on it (like the recent Abolish votes) a 2/3 bar would suffice -
although I think it's healthy for everyone that the ratio that was reached
was more along the lines of 20 to 1 than 2 to 1, in terms of everyone
accepting the validity of the policy change (including the fingerful who
voted against). But since determining whether a policy RFC falls in that
category or not can in itself be challenging, having a single, clear high
bar for introducing both changes to the Voting RFC, as well new policy
rules, would probably be the simplest and probably healthiest outcome.Regarding the 2nd (fundamental / high impact changes) - the solution here
too would be consensus based decision making. That's the bar we cleared in
previous major changes - the deprecation of register_globals, magic_quotes
and safe_mode. Now, I think Nikita does have a point that defining what
constitutes a 'high impact' break vs. one that isn't very easy - especially
in a formal manner. So it may make sense to have a single bar for all
compatibility breaking changes, instead of a separate one for high impact
ones and low impact ones. The solution might be to simply gauge the level
of caring through the number of voters who took the time to vote. For
instance, a change proposal that garnered 10 votes, 7 to 3, is probably not
a high-impact one and it may be reasonable to accept it even if it only
cleared a 2 to 1 ratio. A change proposal that garners 50 votes and is 35
in favor and 15 against (exactly the same ratio, but with a lot more
voters) - is most probably a high impact one, and should clear a much
higher consensus-level bar. In the meantime, formality aside, it's easy
enough to 'know it when you see it'. I don't think anybody contends that
changing our undefined variable behavior or deprecating short tags are
high-impact breaks - in terms of the lines of code in the combined
universal PHP code base that would have to be changed as a result.
I think everything needs to be properly defined before a vote starts. So, I
don't think you can base the level of consensus required on how many people
vote. I also think that high impact changes (if not all BC breaking
changes) should require a certain minimum number of votes as well (a
quorum, so to speak).
Other than the higher bar - I think such proposals should be required (or
at the very least encouraged) to do a better impact analysis regardless.
They should be tested on a set of apps (one that will attempt to represent
the PHP codebase at large, not just the cutting-edge framework
development), and the results should be available as a part of the RFC.
Even if we can't formally compute from that data whether it constitutes
high-impact or not, having that data as a part of the RFC will likely help
voters determine their opinion on it - first at the level of whether they
care or not, and secondly - whether they're in favor or not. This will, in
turn, effect voter turnout - and help determine whether this is indeed a
major change or not.
I think this would be a very good thing to do. There currently isn't a way
for userland developers to vote on any of these proposals. I really don't
know of a good way to allow them to, either. While some sort of
representation might be worth considering in the future, I think this would
be a good first step. It would give some sort of voice to userland
developers by at least gauging the impact of the proposed changes against
some of the more widely used libraries. I also think the tools used for the
analysis should be made available so that developers that can't make their
code available can still run the analysis on their code and report the
findings.
Yes, this might put an additional burden on the RFC author, but I don't
think that is a bad thing. If we're considering something that might put a
large burden on other PHP developers that don't even get a vote, the very
least we can do is require the person proposing the change do their due
diligence.
In addition, I don't think we should be grouping any deprecations together
into a single vote - unless that's absolutely required from a technical
standpoint (i.e. doing one without the other would lead to an
inconsistency). With the recent engine errors reclassification RFC,
initially - the deprecation of default values for uninitialized variables
wasn't even viewed as a very big deal and was grouped with the rest. It's
true that this quickly became apparent and Nikita separated it after a
couple of days - but I think that should be a requirement, and not up to
the RFC author. I also agree with Christian - the fact that this
deprecation was by far the biggest one - basically distracted everyone
(myself included) from discussing the smaller ones. This means that while
there are probably some issues with some of the other, smaller changes -
the fact they're lumped together with others which are harmless, and the
fact there was practically no discussion over any of them - means it's all
too easy to vote in favor of changing the entire group. Combined with no
impact analysis being available for each proposal - it's very likely that
there's 'herd mentality' happening there. Putting each in a separate vote
would have likely not thoroughly solved this, but it would have probably
been a good first step, allowing more granular choice. I think that this
particular change (requiring separate votes for each change) can be done
relatively easily within our existing framework - similar to the Abolish
RFCs, if there's widespread agreement. In the context of Ben's email from
a few weeks ago, I'll defer to someone else to propose it if they think it
makes sense.Zeev
--
Chase Peeler
chasepeeler@gmail.com
Thank you Zeev,
I would say it's something to start a more productive discussion.
Maybe not everybody would agree from the start with what you mentioned but
after resonable talks, it would get to some common conclusions.
If I were to summarize, there needs to be defined the voting process for:
- RFCs for new features or changes with no or very small BC breaks.
- RFCs for new features and changes with small BC breaks and/or breaks
that can be fixed with ease. - RFCs for new features and changes with medium BC breaks and/or breaks
that can be fixed with some effort. - RFCs for how voting process takes place including structural or
governance change.
For now, possibly the 1. and 2. voting can stay at 2/3.
Voting for 3. can be moved to 4/5 or higher.
Voting for 4. can be moved to 6/7 or higher or can be splitted if different
acceptance would be required after discussion.
That's closer to consensus.
One other thing to define would be who is the PHP group and who are the
voting members.
This can be something based on code activity in the last 4, 5 years or
someting similar, top 30/40 persons by number of commits/lines
changed/something measurable. As Rasmus put it, "The people writing the
code get to call the shots, for better or worse."
And to have relevant people for voting, they can vote somehow on another
15/20 persons from relevant companies/frameworks.
Now it would be great if someone would take the time to draft a proposal of
defining what's not defined, of course with more relevant options and
numbers as I don't think I have proper expertise here.
And of course including all the other details about how a RFC should look
like for each type.
Let's try as much as possible to be constructive as otherwise everybody has
something to lose.
Thank you,
Alex
On Tue, Sep 17, 2019 at 3:32 PM Larry Garfield larry@garfieldtech.com
wrote:Simple question for those that keep arguing that the RFC process is only
applicable to a certain subset of issues:OK, so what's the alternative?
If we wanted to make a structural or governance change to PHP, what is
the
process?
If we really did feel there was a reason to make a fundamental change to
the language (whatever that means), what is the process?
If we wanted to change the RFC process, what is the process?
If we don't have those, and want to set them up, what is the process for
defining the process?For the first and last one (which are kind of the same) - the answer is
simply the (informal) process we had before the RFC process was enacted.
That effectively meant consensus based decision making.
Since we have a lot more people today, we can and probably should reuse the
voting mechanism, and a pass would have to look along the lines of this:https://web.archive.org/web/20120527111218/https://wiki.php.net/rfc/voting/vote
or
https://wiki.php.net/rfc/abolish-short-votesIf you look at all the 'Process and Policy' RFCs we've voted on, other than
a couple that are miscategorized technical RFCs - they virtually all
cleared a 15 to 1 bar, most of them well above that. When changing the
rules - or extending the scope of the RFC process to handle things it never
has before, this is what it takes. We haven't implemented any rules that
bind everyone without that level of widespread agreement to this date.Consensus based decisions would work for the 3rd one as well and would
probably be the simplest to enforce. It may be that for RFCs that place
new limits on it (like the recent Abolish votes) a 2/3 bar would suffice -
although I think it's healthy for everyone that the ratio that was reached
was more along the lines of 20 to 1 than 2 to 1, in terms of everyone
accepting the validity of the policy change (including the fingerful who
voted against). But since determining whether a policy RFC falls in that
category or not can in itself be challenging, having a single, clear high
bar for introducing both changes to the Voting RFC, as well new policy
rules, would probably be the simplest and probably healthiest outcome.Regarding the 2nd (fundamental / high impact changes) - the solution here
too would be consensus based decision making. That's the bar we cleared in
previous major changes - the deprecation of register_globals, magic_quotes
and safe_mode. Now, I think Nikita does have a point that defining what
constitutes a 'high impact' break vs. one that isn't very easy - especially
in a formal manner. So it may make sense to have a single bar for all
compatibility breaking changes, instead of a separate one for high impact
ones and low impact ones. The solution might be to simply gauge the level
of caring through the number of voters who took the time to vote. For
instance, a change proposal that garnered 10 votes, 7 to 3, is probably not
a high-impact one and it may be reasonable to accept it even if it only
cleared a 2 to 1 ratio. A change proposal that garners 50 votes and is 35
in favor and 15 against (exactly the same ratio, but with a lot more
voters) - is most probably a high impact one, and should clear a much
higher consensus-level bar. In the meantime, formality aside, it's easy
enough to 'know it when you see it'. I don't think anybody contends that
changing our undefined variable behavior or deprecating short tags are
high-impact breaks - in terms of the lines of code in the combined
universal PHP code base that would have to be changed as a result.Other than the higher bar - I think such proposals should be required (or
at the very least encouraged) to do a better impact analysis regardless.
They should be tested on a set of apps (one that will attempt to represent
the PHP codebase at large, not just the cutting-edge framework
development), and the results should be available as a part of the RFC.
Even if we can't formally compute from that data whether it constitutes
high-impact or not, having that data as a part of the RFC will likely help
voters determine their opinion on it - first at the level of whether they
care or not, and secondly - whether they're in favor or not. This will, in
turn, effect voter turnout - and help determine whether this is indeed a
major change or not.In addition, I don't think we should be grouping any deprecations together
into a single vote - unless that's absolutely required from a technical
standpoint (i.e. doing one without the other would lead to an
inconsistency). With the recent engine errors reclassification RFC,
initially - the deprecation of default values for uninitialized variables
wasn't even viewed as a very big deal and was grouped with the rest. It's
true that this quickly became apparent and Nikita separated it after a
couple of days - but I think that should be a requirement, and not up to
the RFC author. I also agree with Christian - the fact that this
deprecation was by far the biggest one - basically distracted everyone
(myself included) from discussing the smaller ones. This means that while
there are probably some issues with some of the other, smaller changes -
the fact they're lumped together with others which are harmless, and the
fact there was practically no discussion over any of them - means it's all
too easy to vote in favor of changing the entire group. Combined with no
impact analysis being available for each proposal - it's very likely that
there's 'herd mentality' happening there. Putting each in a separate vote
would have likely not thoroughly solved this, but it would have probably
been a good first step, allowing more granular choice. I think that this
particular change (requiring separate votes for each change) can be done
relatively easily within our existing framework - similar to the Abolish
RFCs, if there's widespread agreement. In the context of Ben's email from
a few weeks ago, I'll defer to someone else to propose it if they think it
makes sense.Zeev
Hi all,
Does anyone object to any of those words ?
This strikes me as yet another attempt at a power grab, so many of the words are objectionable. However, this phrase will serve to show the weakness of the proposal:
Anyone may initiate an RFC for any subject.
There needs to be an articulable limiting principle; without it, there can be no strong continuity, only the current passion of a mob. For example, this phrasing means the RFC system itself can be put up to vote, to be removed and replaced with something entirely non-democratic.
Some things simply have to be off limits. What are those things?
--
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
Some things simply have to be off limits. What are those things?
PHP doesn't currently have a constitution, so currently voting is the
only way of deciding things. Also how we vote is one of the things
that people are allowed to vote on.
Even if we had a constitution, like the US does there would still need
to be ways of changing it,
https://en.wikipedia.org/wiki/Constitutional_amendment
This strikes me as yet another attempt at a power grab
...only the current passion of a mob.
Your opinion would have more weight if you contributed more to
internals, other than popping by occasionally to say nasty things to
people.
cheers
Dan
Ack
Hi!
Does anyone object to any of those words ?
Yes. I do not think precommitting to implement anything that has been
put on wiki and passed the vote is a good thing. Its a good conflict
resolution mechanism when we're talking about where or not to implement
certain technical feature. But IMO it would be terrible as a sole
governance mechanism for the whole project.
Do we need to vote on changing the introduction (I'm happy to start an rfc
for this, if necessary) ?
I don't think RFCs were meant to essentially remake all project
governance structure. They were meant for solving technical questions,
not governance model.
I am not sure which way would be the best (haven't thought about it) but
certainly neither just putting some words on wiki nor voting on it
within the RFC process looks like a good way to do it.
--
Stas Malyshev
smalyshev@gmail.com
Do we need to vote on changing the introduction (I'm happy to start an rfc
for this, if necessary) ?I don't think RFCs were meant to essentially remake all project
governance structure. They were meant for solving technical questions,
not governance model.
Then we should undo all changes (as far as possible) caused by the RFCs
listed in the Process and Policy section[1], probably starting with the
Voting (aka. RFC) process RFC itself, which by the way, states as
introduction since its very first version from 2011 (emphasis mine):
| This document describes the procedure to propose an idea for
| adoption by the PHP community and decide if the community accepts or
| rejects the idea.
Thanks,
Christoph
Hi!
Then we should undo all changes (as far as possible) caused by the RFCs
listed in the Process and Policy section[1], probably starting with the
Voting (aka. RFC) process RFC itself, which by the way, states as
introduction since its very first version from 2011 (emphasis mine):| This document describes the procedure to propose an idea for
| adoption by the PHP community and decide if the community accepts or
| rejects the idea.
Proposing an idea for adoption is not the same as precommitting on
implementing anything that has been voted on, including whole governance
of the project.
I did not suggest undoing anything, and there's really no need to put
words in my mouth, I can speak for myself.
Thanks,
Stas Malyshev
smalyshev@gmail.com
Hi Joe
Den søn. 15. sep. 2019 kl. 08.48 skrev Joe Watkins krakjoe@php.net:
Morning internals,
There is confusion among the community, and contained in the documented
history of PHP on the wider internet.The Wikipedia states that PHP is developed by the PHP Group, in saying this
it is (must be) referring to internals as a whole, but our own
documentation names members of the group - who aren't even around mostly.I think we need to clarify what exactly is the purpose of the PHP Group
today, does anyone want to attempt to do that ?
This is speculation/my interpretation, so take this with a grain of
salt; I think The PHP Group was the project governance back in the
day, but with PHP's ever so vastness and expansion, new developers
come in, old developers go all the time, I don't think this ever got
to be what it was meant to be. Now a days it mostly seems to serve as
a legacy of the past.
Given the recent clarification from Rasmus, I do not think the name
has any meaning anymore besides being a fancy name that holds the
copyright, whereas the copyright probably should be updated to be:
"Copyright (C) The PHP Project", on the PHP.net website, license et
al. Besides this I cannot think of a place where I have seen a
definition of "The PHP Group" or seen it active besides its recent
mention of being an "authoritative" power (which clearly is not the
case as there is no legal ramification to hold this statement true).
(I picked "The PHP Project" over "The PHP Development Team" which is
also commonly used to include everyone who contributes time and
resources to PHP).
Whatever it's purpose, if it has one, we need to make clear at this time
that there are no vetos: As Rasmus clarified, PHP is driven by the people
who write PHP: No member of any group or company, historical or otherwise,
has any veto powers, they cannot, and they must not behave as if they do.I would like to update the introduction to the Voting RFC:
The development of PHP is community driven by the RFC process described in
this document. Anyone may initiate an RFC for any subject. At the end of
the RFC process a vote is held among PHP developers to determine if the
proposal is to be accepted.Should a proposal be accepted, the developers of PHP are committed to
making the change.In some circumstances, merging an implementation into the source code of
PHP may be delayed because of shortcomings in that implementation. In these
cases, resolution of these shortcomings is the responsibility of the
proposer.Should a proposal be accepted without an implementation, it is the
responsibility of the proposer to provide one.Does anyone object to any of those words ?
Do we need to vote on changing the introduction (I'm happy to start an rfc
for this, if necessary) ?
I got no objection to adding it, but perhaps an RFC should be more in
the direction of a "Mission statement" of sorts, stating what the
project is, what our goals are, who steers the direction etc. This
could be a decent start to sorting out the strings.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Morning internals,
I've got some good feedback here, my suggested words were indeed rather
loose.
I'd like it if we could stop saying the RFC process can't be used for one
thing or another, it's patently false.
The RFC process introduced itself, amends itself, is used for deprecation,
addition, and removal.
To say it's not suitable for these things is a total nonsense, we already
use it for these things.
I think maybe my use of the word "commit" was misunderstood.
It is the case that a positive result means we are in some sense committed
to merging the change (when a patch becomes available as in the case of
null coalesce assign). I went to the effort of mentioning the specific case
where an implementation is not suitable. Obviously other cases may arise
where the decision is reversed by a follow up RFC, I thought this
possibility was implicit.
A note on the group issue:
When I said it's not well defined, I didn't mean we don't have a list of
names, quite the opposite, we have a list of names that are mostly
unconnected to the project today. What we don't have is a definition of the
role of the Group, specifically one that fits the project as it is today.
This undeniably causes confusion and a certain amount of friction, both
during interactions between internals members and in the wider community.
Thanks for all the input, I'll give this some more thought ...
Cheers
Joe
Hi Joe
Den søn. 15. sep. 2019 kl. 08.48 skrev Joe Watkins krakjoe@php.net:
Morning internals,
There is confusion among the community, and contained in the documented
history of PHP on the wider internet.The Wikipedia states that PHP is developed by the PHP Group, in saying
this
it is (must be) referring to internals as a whole, but our own
documentation names members of the group - who aren't even around mostly.I think we need to clarify what exactly is the purpose of the PHP Group
today, does anyone want to attempt to do that ?This is speculation/my interpretation, so take this with a grain of
salt; I think The PHP Group was the project governance back in the
day, but with PHP's ever so vastness and expansion, new developers
come in, old developers go all the time, I don't think this ever got
to be what it was meant to be. Now a days it mostly seems to serve as
a legacy of the past.Given the recent clarification from Rasmus, I do not think the name
has any meaning anymore besides being a fancy name that holds the
copyright, whereas the copyright probably should be updated to be:
"Copyright (C) The PHP Project", on the PHP.net website, license et
al. Besides this I cannot think of a place where I have seen a
definition of "The PHP Group" or seen it active besides its recent
mention of being an "authoritative" power (which clearly is not the
case as there is no legal ramification to hold this statement true).(I picked "The PHP Project" over "The PHP Development Team" which is
also commonly used to include everyone who contributes time and
resources to PHP).Whatever it's purpose, if it has one, we need to make clear at this time
that there are no vetos: As Rasmus clarified, PHP is driven by the people
who write PHP: No member of any group or company, historical or
otherwise,
has any veto powers, they cannot, and they must not behave as if they do.I would like to update the introduction to the Voting RFC:
The development of PHP is community driven by the RFC process described
in
this document. Anyone may initiate an RFC for any subject. At the end of
the RFC process a vote is held among PHP developers to determine if the
proposal is to be accepted.Should a proposal be accepted, the developers of PHP are committed to
making the change.In some circumstances, merging an implementation into the source code of
PHP may be delayed because of shortcomings in that implementation. In
these
cases, resolution of these shortcomings is the responsibility of the
proposer.Should a proposal be accepted without an implementation, it is the
responsibility of the proposer to provide one.Does anyone object to any of those words ?
Do we need to vote on changing the introduction (I'm happy to start an
rfc
for this, if necessary) ?I got no objection to adding it, but perhaps an RFC should be more in
the direction of a "Mission statement" of sorts, stating what the
project is, what our goals are, who steers the direction etc. This
could be a decent start to sorting out the strings.--
regards,Kalle Sommer Nielsen
kalle@php.net
Hi!
I'd like it if we could stop saying the RFC process can't be used for one
thing or another, it's patently false.
Not can't, shouldn't be. And I don't see any reason why we should stop
saying that.
To say it's not suitable for these things is a total nonsense, we already
use it for these things.
Contrary to popular belief, saying the magic word "nonsense" doesn't
actually prove anything and doesn't replace actual argument.
RFC process was not created to be sole governing body for PHP project
and something that makes every vote mandatory for the whole project. If
there's a consensus about certain decision, sure, it can be confirmed by
a vote, but if there's no consensus about some thing like project
governance, then just holding a vote for two weeks in random point of
time among those who happens to read the list at that time is not a good
governance model.
RFC process is fine for committing features because worst thing we
commit some bad code, and revert/amend it later. It's a bit dangerous
for deep language features since rolling that back would be hard. But I
do not think governing the project can be done in this way. Fortunately,
PHP project actually doesn't need a lot of "governing", but when the
need arises, just holding a two-week vote among whoever happens to read
the list in those two weeks - I don't think that would work very well.
Stas Malyshev
smalyshev@gmail.com
Stas,
Not can't, shouldn't be. And I don't see any reason why we should stop
saying that.
Because it's a waste of everyone's time. The RFC process is the only one we
have.
RFC process was not created to be sole governing body for PHP project
and something that makes every vote mandatory for the whole project.
I'm not sure exactly what this means.
To clarify, I wasn't trying to impose anything new by changing the
introduction, I was only trying to give a formal description of how the
project actually does work, and what role the RFC process plays in that.
I already conceded that my words were loose and I done a pretty poor job of
doing that.
but if there's no consensus about some thing like project
governance, then just holding a vote for two weeks in random point of
time among those who happens to read the list at that time is not a good
governance model.
Your suggestion implies that if there was no consensus about how the
project is governed that it would be our only option to continue without a
way to resolve that question.
In reality, there is a consensus about how the project is governed. Some
contributors may be unhappy, and far too loud about expressing their
opinions on this, but they are a small minority.
The vast majority of contributors are quite happy to use the RFC process in
all the ways we have been using it.
Cheers
Joe
On Mon, 16 Sep 2019 at 09:52, Stanislav Malyshev smalyshev@gmail.com
wrote:
Hi!
I'd like it if we could stop saying the RFC process can't be used for one
thing or another, it's patently false.Not can't, shouldn't be. And I don't see any reason why we should stop
saying that.To say it's not suitable for these things is a total nonsense, we already
use it for these things.Contrary to popular belief, saying the magic word "nonsense" doesn't
actually prove anything and doesn't replace actual argument.RFC process was not created to be sole governing body for PHP project
and something that makes every vote mandatory for the whole project. If
there's a consensus about certain decision, sure, it can be confirmed by
a vote, but if there's no consensus about some thing like project
governance, then just holding a vote for two weeks in random point of
time among those who happens to read the list at that time is not a good
governance model.RFC process is fine for committing features because worst thing we
commit some bad code, and revert/amend it later. It's a bit dangerous
for deep language features since rolling that back would be hard. But I
do not think governing the project can be done in this way. Fortunately,
PHP project actually doesn't need a lot of "governing", but when the
need arises, just holding a two-week vote among whoever happens to read
the list in those two weeks - I don't think that would work very well.Stas Malyshev
smalyshev@gmail.com
Hi!
Because it's a waste of everyone's time. The RFC process is the only one
we have.
So? There was time where we had none. Processes are not some precious
jewels that we occasionally happen to find by chance but can't have any
more. We can create them.
To clarify, I wasn't trying to impose anything new by changing the
introduction, I was only trying to give a formal description of how the
project actually does work, and what role the RFC process plays in that.
I don't think I agree that the project works that way, at least the way
I understood what you wrote. Maybe my understanding did not match your
intent, but then we need a formulation that would express that intent
more clearly, so that myself and others would understand it properly and
we could agree on it.
Your suggestion implies that if there was no consensus about how the
project is governed that it would be our only option to continue without
a way to resolve that question.
No, it's not the only option. I am just saying that having an RFC vote
as defined in RFC process is not the only option, and it's not the
preferable option. We can seek others.
In reality, there is a consensus about how the project is governed. Some
contributors may be unhappy, and far too loud about expressing their
opinions on this, but they are a small minority.
Your definition of "consensus" is very different from mine then. And how
do you know those who disagree with you are "small minority"? Small
compared to what? Minority compared to whom?
The vast majority of contributors are quite happy to use the RFC process
in all the ways we have been using it.
Vast majority of contributors also probably have very little interest in
project governance as long as it delivers the results - i.e. features
get implemented, patches get merged, bugs get fixes, code keeps running.
But when there's disagreement about the overall direction the project
should take, and how to solve it, I don't think anybody ever asked "vast
majority of contributors" about how to solve it and I doubt that vast
majority spent significant time on evaluating the merits of potential
solutions to that. In fact, I am not even convinced "vast majority of
contributors" are those who need to decide that - is it really right
that whoever contributed a docs fix or a test couple of times, or maybe
supported one extension, has the same voice on the project direction as
somebody who implemented large pieces of code and spent decades in the
project? That's one of the questions that needs to be considered. There
are likely more.
Stas Malyshev
smalyshev@gmail.com
This note isn't really for Joe, who will likely would not pay too much if
any attention to whatever I or whomever else who disagrees with his
position on the universal applicability of the Voting RFC in its current
form has to say.
This is for the many other folks following this and other threads.
I'd like it if we could stop saying the RFC process can't be used for one
thing or another, it's patently false.
Saying that something is patently false doesn't make it so. Repeating it
in multiple ways doesn't make it so either. And indeed, the RFC process
can be used for a wide range of use cases - and at the same time it isn't
and never was a way to govern every aspect of the project. The notion of
'one size fits all' is frankly ridiculous.
This process was introduced in a certain context, and while it's true that
it evolved to also cover some other elements it never ventured into
radically different areas as it appears to be doing now. Currently, it's
mutating to cover an entirely new space - the space of radical breaks -
it's time to put it back in perspective, and agree on how we're going to
handle these things going forward.
To say it's not suitable for these things is a total nonsense, we already
use it for these things.
Determining that a process that was devised for a certain purpose is
suitable for every other purpose under the sun is, in my humble opinion,
not very sensible. Adding a feature and taking it away - let alone so
after 20 years - have radically different effects. The former doesn't
immediately do anything (at least not negatively). The latter - depending
on the details - could have far reaching overnight effects. It's not just
that the RFC process wasn't meant to cover that. It's that treating both
cases as if they're the same thing doesn't make any sense at all.
Yes, using the process itself to amend it was a bit questionable - but
since it did not extend the scope and jurisdiction, it wasn't a big deal.
It also passed nearly unanimously - so whatever bar we would have had, it
would have likely cleared it. It does not mean that the same process with
the same bar can be used to extend its jurisdiction to additional areas.
Specifically, areas where it cannot extend itself into are the areas such
as radical changes to the project governance and radical shifts in the
language.
It's not that the process in itself is not suitable. Much of it can be
reused for these purposes. However, if we are going to make radical
changes - be them in the language or in how we work - there needs to be
overwhelming support for it - similarly to the level of support we had for
the RFC process itself and its amendments. Also similarly to when we
deprecated major features like like register_globals, safe_mode and
magic_quotes - there was also near unanimous support for it, which was more
along the lines of 10 to 1 than 2 to 1. And arguably - all three were much
'smaller deals' than the radical deprecation that is currently on the table
- register_globals and magic_quotes had simple one liner workarounds, and
safe_mode had its scope limited to shared hosters only - and was (almost)
unanimously agreed upon as a feature that was simply not working as
advertised.
If we want to extend the Voting RFC to cover things such as radical changes
to the language, or introduce radical changes to the project governance
(e.g. CoC) - it would have to clear a similar bar. You need overwhelming
support for changing the rules that bind everyone. Yes, I realize people
think that it is me who's changing the rules - but it isn't. It's no
coincidence that the applicability of the RFC process is coming into
question now - it's being used - for the first time in a few short months -
to do something it was very clearly not designed to do. It simply never
happened before.
It's not that we can't apply large parts of the RFC process to these areas
as well. We can and should. But we'd have to modify some elements and add
some others.
For areas like radical changes in project governance (i.e., not amending
the Voting RFC within the same scope, but say, extending it; Or
introducing a CoC) - it would have to clear a much higher bar. Whether
it's 5 to 1 or 10 to 1, it can clearly not be 2 to 1.
Similarly, for deprecations - we'd need a way to measure the expected
impact, and determine the bar in correlation to that expected impact.
Deprecations with minor impact could perhaps still use the 2/3 bar.
Radical shifts that are going to affect hundreds of thousands of people or
require auditing of billions of lines of code - would have to clear a much
higher bar - and would have to include a much stronger analysis than 5
sentence in a composite RFC.
The 2/3 bar encourages contention, and worse - as we can see in recent
months - enables tyranny of a majority - forcing change on the minority.
Moreover, the specific recent example of what happened with short_tags
illustrates just how unsuitable the RFC process in its current form is to
handle radical deprecations. The 2/3 bar was meant a reasonable bar to
ensure that the support isn't some temporary "50%+1" - that would then
commit us to perpetually supporting a feature that we weren't too confident
about as a team.
We are in control of a gigantic platform that is used by millions of
people. The RFC process gave folks access to influence the future
direction of PHP in a way that has few if any parallels in Open Source
programming languages. Perhaps this confused people to think that we
(internals) can do whatever we want with it using the same relatively
achievable bar. That is not the case.
On a personal note, I'm well aware that many are perceiving this as if I'm
trying to take control of the project, or driving people away, or generally
being aggressive.
Reality is slightly different. The folks who are triggering these
discussions are the ones who are trying to both bring change to PHP, and at
the same time refuse to compromise or even explore win/win solutions.
Sure, others have the option to just 'suck it up' and see the project we've
worked on and/or have been using for years take a radical turn into being
something different and push us away. In recent months, I've repeatedly
tried to come up with, bring up or accept constructive solutions - that
would not disenfranchise one camp at the expense of the other, but rather
give both camps what they want. But it appears that the current majority
insists that they don't only get what they want - but that they do it while
taking away what the minority wants. This cannot stand. As I said
repeatedly, we need to snap out of the zero sum game mentality and come up
with solutions that work for mostly everyone - certainly not just 2/3 of
internals (and probably a lot less of the PHP world at large).
I'm not saying I can veto decisions, and going down the line of figuring
out whether the PHP Group can do so is the wrong direction that's entirely
non productive. I'm not trying to "take back control" of the project.
There's absolutely nothing personal at play here for me, I wish I didn't
have to be involved in this.
What I am saying that the RFC process in its current form is inapplicable
to the discussions we're currently throwing at it. I'm also suggesting
that we need to move back to be a bit more consensus driven with decisions
that affect everyone. Concensus on such areas doesn't have to and will not
mean paralysis. PHP has evolved a lot in recent years, and will continue
to do so - the 2/3 bar along with the composition of internals@ ensures
that. It's just that if we want to evolve it in a direction that would
negatively affect a very large group of people (break their apps) - we need
to do better than that. There either needs to be an exceptionally good
case for it which would result in overwhelming support - or we need to find
a way to introduce it without breaking people's code. That can absolutely
be done - even in a variety of ways (Editions, strict mode, P++, other
ideas) - it's not even very complicated. All it takes is some good will.
Zeev
This note isn't really for Joe, who will likely would not pay too much if
any attention to whatever I or whomever else who disagrees with his
position on the universal applicability of the Voting RFC in its current
form has to say.
This is for the many other folks following this and other threads.I'd like it if we could stop saying the RFC process can't be used for one
thing or another, it's patently false.Saying that something is patently false doesn't make it so. Repeating it
in multiple ways doesn't make it so either. And indeed, the RFC process
can be used for a wide range of use cases - and at the same time it isn't
and never was a way to govern every aspect of the project. The notion of
'one size fits all' is frankly ridiculous.
This process was introduced in a certain context, and while it's true that
it evolved to also cover some other elements it never ventured into
radically different areas as it appears to be doing now. Currently, it's
mutating to cover an entirely new space - the space of radical breaks -
it's time to put it back in perspective, and agree on how we're going to
handle these things going forward.To say it's not suitable for these things is a total nonsense, we already
use it for these things.
Determining that a process that was devised for a certain purpose is
suitable for every other purpose under the sun is, in my humble opinion,
not very sensible. Adding a feature and taking it away - let alone so
after 20 years - have radically different effects. The former doesn't
immediately do anything (at least not negatively). The latter - depending
on the details - could have far reaching overnight effects. It's not just
that the RFC process wasn't meant to cover that. It's that treating both
cases as if they're the same thing doesn't make any sense at all.Yes, using the process itself to amend it was a bit questionable - but
since it did not extend the scope and jurisdiction, it wasn't a big deal.
It also passed nearly unanimously - so whatever bar we would have had, it
would have likely cleared it. It does not mean that the same process with
the same bar can be used to extend its jurisdiction to additional areas.Specifically, areas where it cannot extend itself into are the areas such
as radical changes to the project governance and radical shifts in the
language.It's not that the process in itself is not suitable. Much of it can be
reused for these purposes. However, if we are going to make radical
changes - be them in the language or in how we work - there needs to be
overwhelming support for it - similarly to the level of support we had for
the RFC process itself and its amendments. Also similarly to when we
deprecated major features like like register_globals, safe_mode and
magic_quotes - there was also near unanimous support for it, which was more
along the lines of 10 to 1 than 2 to 1. And arguably - all three were much
'smaller deals' than the radical deprecation that is currently on the table
- register_globals and magic_quotes had simple one liner workarounds, and
safe_mode had its scope limited to shared hosters only - and was (almost)
unanimously agreed upon as a feature that was simply not working as
advertised.If we want to extend the Voting RFC to cover things such as radical changes
to the language, or introduce radical changes to the project governance
(e.g. CoC) - it would have to clear a similar bar. You need overwhelming
support for changing the rules that bind everyone. Yes, I realize people
think that it is me who's changing the rules - but it isn't. It's no
coincidence that the applicability of the RFC process is coming into
question now - it's being used - for the first time in a few short months -
to do something it was very clearly not designed to do. It simply never
happened before.It's not that we can't apply large parts of the RFC process to these areas
as well. We can and should. But we'd have to modify some elements and add
some others.
For areas like radical changes in project governance (i.e., not amending
the Voting RFC within the same scope, but say, extending it; Or
introducing a CoC) - it would have to clear a much higher bar. Whether
it's 5 to 1 or 10 to 1, it can clearly not be 2 to 1.
Similarly, for deprecations - we'd need a way to measure the expected
impact, and determine the bar in correlation to that expected impact.
Deprecations with minor impact could perhaps still use the 2/3 bar.
Radical shifts that are going to affect hundreds of thousands of people or
require auditing of billions of lines of code - would have to clear a much
higher bar - and would have to include a much stronger analysis than 5
sentence in a composite RFC.The 2/3 bar encourages contention, and worse - as we can see in recent
months - enables tyranny of a majority - forcing change on the minority.
Moreover, the specific recent example of what happened with short_tags
illustrates just how unsuitable the RFC process in its current form is to
handle radical deprecations. The 2/3 bar was meant a reasonable bar to
ensure that the support isn't some temporary "50%+1" - that would then
commit us to perpetually supporting a feature that we weren't too confident
about as a team.We are in control of a gigantic platform that is used by millions of
people. The RFC process gave folks access to influence the future
direction of PHP in a way that has few if any parallels in Open Source
programming languages. Perhaps this confused people to think that we
(internals) can do whatever we want with it using the same relatively
achievable bar. That is not the case.On a personal note, I'm well aware that many are perceiving this as if I'm
trying to take control of the project, or driving people away, or generally
being aggressive.Reality is slightly different. The folks who are triggering these
discussions are the ones who are trying to both bring change to PHP, and at
the same time refuse to compromise or even explore win/win solutions.
Sure, others have the option to just 'suck it up' and see the project we've
worked on and/or have been using for years take a radical turn into being
something different and push us away. In recent months, I've repeatedly
tried to come up with, bring up or accept constructive solutions - that
would not disenfranchise one camp at the expense of the other, but rather
give both camps what they want. But it appears that the current majority
insists that they don't only get what they want - but that they do it while
taking away what the minority wants. This cannot stand. As I said
repeatedly, we need to snap out of the zero sum game mentality and come up
with solutions that work for mostly everyone - certainly not just 2/3 of
internals (and probably a lot less of the PHP world at large).I'm not saying I can veto decisions, and going down the line of figuring
out whether the PHP Group can do so is the wrong direction that's entirely
non productive. I'm not trying to "take back control" of the project.
There's absolutely nothing personal at play here for me, I wish I didn't
have to be involved in this.What I am saying that the RFC process in its current form is inapplicable
to the discussions we're currently throwing at it. I'm also suggesting
that we need to move back to be a bit more consensus driven with decisions
that affect everyone. Concensus on such areas doesn't have to and will not
mean paralysis. PHP has evolved a lot in recent years, and will continue
to do so - the 2/3 bar along with the composition of internals@ ensures
that. It's just that if we want to evolve it in a direction that would
negatively affect a very large group of people (break their apps) - we need
to do better than that. There either needs to be an exceptionally good
case for it which would result in overwhelming support - or we need to find
a way to introduce it without breaking people's code. That can absolutely
be done - even in a variety of ways (Editions, strict mode, P++, other
ideas) - it's not even very complicated. All it takes is some good will.
We heard you repeating the RFC process isn't applicable very often now, but
a productive way forward needs to take it into account to make any change
in governance.
For many of the current contributors RFC+Voting process is the only visible
process that was applied and has been used to make changes to the language
in the last 8 years.
Even if it was not originally envisoned by you or Pierre to be usable for
deprecations or to amend itself, that is what is has been used for the last
few years. In these votes not arbitrary people, but the contributors with
high influence, the current and recent release masters of PHP 5s and 7s
have all participated, and many core code contributors have
overwhelmingly voted for the changes. To me that makes the RFC process
"common law" of the project, and gives the process a very high legitimacy
across many current contributors, and outside by the community for all
changes to the language and project.
As such any move to change that process, without using the RFC+voting
process as the means to arrive such change, will lead to negative
reactions. All the implicit process that may have existed before was not
passed on to the current maintainers. That governance failure from 8 years
ago is something you cannot take back anymore without sparking the stark
reactions we see right now.
Would it be too much to ask accept the voting RFC as more than it was
thought to be and move forward with your ideas about deprecations as an
amendment to the RFC process? then we can finally productively discuss the
exact wording that you are looking for and have a vote about it.
Zeev
We heard you repeating the RFC process isn't applicable very often now, but
a productive way forward needs to take it into account to make any change
in governance.For many of the current contributors RFC+Voting process is the only visible
process that was applied and has been used to make changes to the language
in the last 8 years.Even if it was not originally envisoned by you or Pierre to be usable for
deprecations or to amend itself, that is what is has been used for the last
few years.
I correct this. I did not mention anything alike. Only that legal (not
a lawyer but been there done that), I only listed two things that can
definitely not be done via RFCs, at least not until the license and
the assignment of this license is as it is now.
For the rest, I tend to fully agree with the general feeling, I am
totally fine to use the RFC to change itself, the language or
whatever.
The only thing I dislike a lot is the general tone of these
discussions, that should be different, that makes me sad and really
not willing to participate in any way.
Best,
Pierre
@pierrejoye | http://www.libgd.org
The only thing I dislike a lot is the general tone of these
discussions, that should be different, that makes me sad and really
not willing to participate in any way.Hi everyone,
I just want to second that feeling of Pierre. Im a userland developer and
just wanted to express that as a person outside internals following the
recent discussions, Im really sad for the reason of the tone used, the
amount of human/brain energy used/wasted in these and as someone mentioned
already it may happen certain developers to abandon the project due to all
that. And this is the last thing I would say we all want (both internals
and externals).
In regards to the 2/3 majority - I would say that in case the minority
opposition is very strong (like in the votes on short tags and warning
levels) isnt it possible to reach a compromise? Like acknowledging the vote
but postpone the implementation for another major version? I understand the
majority rule and the rules of the democracy but again according these
rules even when certain decision passes through and there is still very
strong opposition compromises are sought after.
With the above Im not trying to push my point over the specific RFCs - I
fully understand the implications there and have an option on these but
this is offtopic. At this point considering how much stress these have
caused I would say I got to the point that Im fine with either of the
votes/implementations as long as the PHP team doesnt suffer any harm in
terms of loss of people or massive waste of brain effort.
And I understand that this topic is about the governance of the project
etc... just wanted to bring the attention of the group to the fact that
even on 2/3 in certain cases compromises may be needed and this to be taken
into account when deciding on the governance/voting process.
Thank you all
Vesko Kenashkov
On Mon, Sep 16, 2019 at 7:01 AM Vesselin Kenashkov kenashkov@gmail.com
wrote:
The only thing I dislike a lot is the general tone of these
discussions, that should be different, that makes me sad and really
not willing to participate in any way.Hi everyone,
I just want to second that feeling of Pierre. Im a userland developer and
just wanted to express that as a person outside internals following the
recent discussions, Im really sad for the reason of the tone used, the
amount of human/brain energy used/wasted in these and as someone mentioned
already it may happen certain developers to abandon the project due to all
that. And this is the last thing I would say we all want (both internals
and externals).In regards to the 2/3 majority - I would say that in case the minority
opposition is very strong (like in the votes on short tags and warning
levels) isnt it possible to reach a compromise? Like acknowledging the vote
but postpone the implementation for another major version? I understand the
majority rule and the rules of the democracy but again according these
rules even when certain decision passes through and there is still very
strong opposition compromises are sought after.In regards to error levels RFC, many of us that strongly felt we shouldn't
do what was proposed at all, were at least willing to accept a compromise
where the changes became opt-in via ini settings or a declare. Both of
these suggestions were strongly rejected by those in favor of the RFC.
With the above Im not trying to push my point over the specific RFCs - I
fully understand the implications there and have an option on these but
this is offtopic. At this point considering how much stress these have
caused I would say I got to the point that Im fine with either of the
votes/implementations as long as the PHP team doesnt suffer any harm in
terms of loss of people or massive waste of brain effort.And I understand that this topic is about the governance of the project
etc... just wanted to bring the attention of the group to the fact that
even on 2/3 in certain cases compromises may be needed and this to be taken
into account when deciding on the governance/voting process.Thank you all
Vesko Kenashkov
--
Chase Peeler
chasepeeler@gmail.com
On Mon, Sep 16, 2019 at 1:18 PM Benjamin Eberlei kontakt@beberlei.de
wrote:
We heard you repeating the RFC process isn't applicable very often now,
but a productive way forward needs to take it into account to make any
change in governance.
I think it can actually be taken into account. As I wrote - we can
probably reuse much of it, in terms of voter eligibility, process, etc. -
but the clearance bar is simply unfit for the purpose. Again - not only
because it was never intended for that, but because it doesn't make any
sense.
For many of the current contributors RFC+Voting process is the only
visible process that was applied and has been used to make changes to the
language in the last 8 years.
True, but for them - these two recent RFCs (short tags and even much more
so, the current proposal to do away with default values for undefined
variables) are the first instances of grandiose compatibility breakages
that affect a sizable percentage of the PHP userbase and codebase. Yes,
we've had some deprecations in the past that used this process - but they
all had very limited impact. None of them was even remotely close to
either of those.
In these votes not arbitrary people, but the contributors with high
influence, the current and recent release masters of PHP 5s and 7s have all
participated, and many core code contributors have overwhelmingly voted
for the changes. To me that makes the RFC process "common law" of the
project, and gives the process a very high legitimacy across many current
contributors, and outside by the community for all changes to the language
and project.
As such any move to change that process, without using the RFC+voting
process as the means to arrive such change, will lead to negative
reactions. All the implicit process that may have existed before was not
passed on to the current maintainers. That governance failure from 8 years
ago is something you cannot take back anymore without sparking the stark
reactions we see right now.
Again, there are no instances of radical governance changes - in fact, the
two RFCs that amended the Voting RFC in fact placed new limits on it (by
raising the bar), rather than extended its reach.
Similarly - none of the RFCs we voted on so far had an impact that is
remotely close to the two recent RFCs at hand. As Remi said - PHP 7 - the
first version to extensively use the RFC process, was a good version with
very good BC - with migrations relatively very straightforward. These two
RFCs are the first time the process is being used for something like that.
In fact, I'm hard pressed to think of any break that is at the same level
as the removal of default values for undefined variables. It's not only
something the likes of which we never voted on - we've never done something
like that, even before the RFC process was enacted.
So, it's not as if we've gotten used to making radical changes to the
project governance, or that we've been deprecating fundamental features
left and right - and now suddenly somebody's pulling the brakes. We
haven't been doing that. This is new stuff.
Would it be too much to ask accept the voting RFC as more than it was
thought to be and move forward with your ideas about deprecations as an
amendment to the RFC process?
It's already evolved to be more than what it was originally - which is OK.
But between something that governs slightly more than what it was intended
to - and something that governs everything and anything - there's still a
big gap.
then we can finally productively discuss the exact wording that you are
looking for and have a vote about it.
This isn't so much about wording. Reusing the procedures in the Voting RFC
is probably mostly fine - it's the bar that's problematic.
Let's ascend for a second from the procedural question and look at the
substance.
We're currently at a situation where it appears clear that there's a
majority of folks here that want to go in a certain direction, while
completely disregarding the minority. We're not talking about new features
(that the internals@ minority and beyond can dislike, but can simply choose
to ignore) - we're talking about radical changes to PHP that the internals@
majority wants to force on the internals@ minority, as well as the rest of
the world. There are no attempts being made to cater to the requests,
needs or concerns of the minority. In fact, many in the majority
repeatedly state that their goal is eliminating what the minority wants to
keep. Their win is the others' loss, by definition, purposely and
intentionally.
We are at a new stage - a stage where fundamental features that have been
with us for over 20 years are suddenly on the chopping block. We've never
done things like that with a 2/3 majority. It doesn't make sense to do
these things in a 2/3 majority. It's wrong, it's contentious, it's bad for
both life on internals@ and life beyond it. Even if the minority manages
to 'win' (after being forced to spend tons of energy just to defend the
status quo) - it creates widespread negative feelings in both camps. This
process virtually guarantees a very high number of losers - on both
internals@ and beyond.
One way to solve it is amending the Voting RFC to extend to high-impact
deprecations. We can use the existing voting mechanism for this, but much
like other times where we changed the rules - we need an overwhelming
majority to do that. I could be wrong, but my guess is that if we simply
explicitly add that radical compatibility-breaking language changes or
governance issues are simply covered as-is - it will not garner nearly the
same level of support that the original RFC and its two amendments won. We
need something virtually everyone can live with, not just two thirds of the
voters.
Another way (not mutually exclusive), which I personally think is better
for the range of topics we seem to be discussing lately - is to snap out of
the "your loss is my win" way of thinking. The folks who want to make PHP
stricter can get what they want and do it in an opt-in way - the way we've
always done things in PHP - without forcing everyone else to do the same.
This would make high-impact deprecations a very uncommon occurrence, ones
which will truly have a strong case (like register_globals and safe_mode) -
would likely garner very widespread support. Again, this is very very
doable. All it takes is some good will.
Zeev
Good afternoon Joe,
There is confusion among the community, and contained in the documented
history of PHP on the wider internet.The Wikipedia states that PHP is developed by the PHP Group, in saying this
it is (must be) referring to internals as a whole, but our own
documentation names members of the group - who aren't even around mostly.
The wording there is wrong, that could be fixed.
Many are still around. But that does not matter much in this case. See below.
I think we need to clarify what exactly is the purpose of the PHP Group
today, does anyone want to attempt to do that ?Whatever it's purpose, if it has one, we need to make clear at this time
that there are no vetos: As Rasmus clarified, PHP is driven by the people
who write PHP: No member of any group or company, historical or otherwise,
has any veto powers, they cannot, and they must not behave as if they do.
The RFC process defines a veto and could be applied when needed.
Luckily it never happened. That does not mean it can never be applied,
there are cases where it will happen, by default.
I would like to update the introduction to the Voting RFC:
The development of PHP is community driven by the RFC process described in
this document. Anyone may initiate an RFC for any subject. At the end of
the RFC process a vote is held among PHP developers to determine if the
proposal is to be accepted.
Licenses changes, licenses (c) and related areas cannot be done via
RFCs, at all. While the PHP Group solution is not ideal, it is/was the
less cumbersome one we have as of now.
We also discussed many times if having a foundation could help, which
allows more changes easily but it was never considered worth it as a
non invasive, mostly neutral group, works just fine. A foundation is
really hard to create (where? US? EU? Other?), how would be the board
elected? who will fund it? Which model? Apache? .net? Other? This is
not something that can be done via a RFC.
Should a proposal be accepted, the developers of PHP are committed to
making the change.
A blatantly wrong proposal introducing major flaws in the languages
could be vetoed as that is why the veto clause was introduced (f.e.
impacting massively the security or the performance of the language).
As mentioned already, it luckily never happened.
Should a proposal be accepted without an implementation, it is the
responsibility of the proposer to provide one.Does anyone object to any of those words ?
Do we need to vote on changing the introduction (I'm happy to start an rfc
for this, if necessary) ?
I am not sure changing the words will affect these cases. We do need
more clarity, that is a sure thing, but we do have to be clear about
what is possible and what not.
Also on a side note, I have lived 4 major versions and every single of
them has been a mid life crisis situation for the PHP project. This is
something I would like (no idea how) to address. My key point since at
least after 5 is that we can decide to do one anytime we want. And all
these discussions could be much more smooth if we could keep that in
mind. F.e. each of them had major focus, either OO introduction,
rewrite of the engine (happened 2-3 times before) are some of the
focus major versions had. Everything else are bonuses. In short, the
main issue I can see is the feeling that we won't have another major
version in our lifetime, which is wrong. Some new joiners may see it
like this as they only know 7 since they joined with 5.x (as an
example). Last but not least, this lack of focus was what killed php6
and created the first major crisis in the php project and costs us
some of the core team (who left afterwards, be because of this or
because this failure was the drop too much).
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
I don't think there is a valid way to define "fundamental BC breaks" or
"mere BC breaks", all votes will always be a reasonable vote as much as
there are people to vote on it.
Whats special or different about BC break that would require slim margin or
consensus votes on where this is dealing with people from various
continent, language and ethnic?
Would that imply you don't want any BC breaks at all?
I think if there's any valid arguments against or for any RFCs or votes,
the internals at that time can determine how best to make the voting work.
I don't see any good or valid reason to make a kind of change requiring a
special kind of vote that looks like it was intended to never pass, why 10
to 1?
Does that mean everyone must agree to some kind of change and because
there's 3 people not agreeing, such votes must be counted invalid?
I think this isn't a good decision IMO.
Majority should always be majority regardless of who seems to be in the
minority.
Why don't some people like being in the minority group, which whenever such
happens they would look for a way to gather public minorities to argue
their cause or probably edit RFCs to notify newer voters about who is
disagreeing?