Re: [PHP-DEV] Defining the PHP Group

This is only part of a thread. view whole thread
  107106
September 15, 2019 13:16 zeev@php.net (Zeev Suraski)
On Sun, Sep 15, 2019 at 2:37 PM Peter Bowyer <phpmailinglists@gmail.com>
wrote:

> On Sun, 15 Sep 2019 at 06:48, Joe Watkins <krakjoe@php.net> 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
  107107
September 15, 2019 13:43 Danack@basereality.com (Dan Ackroyd)
On Sun, 15 Sep 2019 at 14:16, Zeev Suraski <zeev@php.net> wrote:
> > 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
  107151
September 16, 2019 08:35 phpmailinglists@gmail.com (Peter Bowyer)
On Sun, 15 Sep 2019 at 14:16, Zeev Suraski <zeev@php.net> 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.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
  107152
September 16, 2019 08:49 krakjoe@gmail.com (Joe Watkins)
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:
> On Sun, 15 Sep 2019 at 14:16, Zeev Suraski <zeev@php.net> 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.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 >
  107154
September 16, 2019 09:01 pierre.php@gmail.com (Pierre Joye)
On Mon, Sep 16, 2019 at 3:49 PM Joe Watkins <krakjoe@gmail.com> wrote:
> > 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,
  107155
September 16, 2019 09:04 pierre.php@gmail.com (Pierre Joye)
On Mon, Sep 16, 2019 at 4:01 PM Pierre Joye php@gmail.com> wrote:
> > On Mon, Sep 16, 2019 at 3:49 PM Joe Watkins <krakjoe@gmail.com> wrote: > > > > 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
  107158
September 16, 2019 09:25 krakjoe@gmail.com (Joe Watkins)
Pierre,

I repeat, there are no vetos, for anyone.

Cheers
Joe

On Mon, 16 Sep 2019 at 11:04, Pierre Joye php@gmail.com> wrote:

> On Mon, Sep 16, 2019 at 4:01 PM Pierre Joye php@gmail.com> wrote: > > > > On Mon, Sep 16, 2019 at 3:49 PM Joe Watkins <krakjoe@gmail.com> wrote: > > > > > > 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 >
  107159
September 16, 2019 09:35 pierre.php@gmail.com (Pierre Joye)
Hi Joe,

On Mon, Sep 16, 2019 at 4:25 PM Joe Watkins <krakjoe@gmail.com> wrote:
> > 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
  107160
September 16, 2019 09:40 krakjoe@gmail.com (Joe Watkins)
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

On Mon, 16 Sep 2019 at 11:35, Pierre Joye php@gmail.com> wrote:

> Hi Joe, > > On Mon, Sep 16, 2019 at 4:25 PM Joe Watkins <krakjoe@gmail.com> wrote: > > > > 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 >
  107183
September 16, 2019 23:56 smalyshev@gmail.com (Stanislav Malyshev)
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
  107190
September 17, 2019 12:32 larry@garfieldtech.com ("Larry Garfield")
On Mon, Sep 16, 2019, at 6:56 PM, Stanislav Malyshev wrote:
> 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
  107193
September 17, 2019 15:41 zeev@php.net (Zeev Suraski)
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
  107194
September 17, 2019 16:45 chasepeeler@gmail.com (Chase Peeler)
I agree with pretty much everything Zeev has said. I've added a few
additional thoughts

On Tue, Sep 17, 2019 at 11:42 AM Zeev Suraski <zeev@php.net> wrote:

> 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. > > 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
  107196
September 17, 2019 20:02 drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)
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:
1. RFCs for new features or changes with no or very small BC breaks.
2. RFCs for new features and changes with small BC breaks and/or breaks
that can be fixed with ease.
3. RFCs for new features and changes with medium BC breaks and/or breaks
that can be fixed with some effort.
4. 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 6:42 PM Zeev Suraski <zeev@php.net> wrote:

> 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 >