Re: [PHP-DEV] Defining the PHP Group

This is only part of a thread. view whole thread
  107140
September 16, 2019 07:32 krakjoe@gmail.com (Joe Watkins)
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







On Mon, 16 Sep 2019 at 05:36, Kalle Sommer Nielsen <kalle@php.net> wrote:

> 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 >
  107143
September 16, 2019 07:52 smalyshev@gmail.com (Stanislav Malyshev)
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
  107145
September 16, 2019 08:01 krakjoe@gmail.com (Joe Watkins)
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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  107147
September 16, 2019 08:17 smalyshev@gmail.com (Stanislav Malyshev)
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
  107157
September 16, 2019 09:05 zeev@php.net (Zeev Suraski)
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.

On Mon, Sep 16, 2019 at 10:33 AM Joe Watkins <krakjoe@gmail.com> wrote:

> 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
  107161
September 16, 2019 10:18 kontakt@beberlei.de (Benjamin Eberlei)
On Mon, Sep 16, 2019 at 11:14 AM Zeev Suraski <zeev@php.net> wrote:

> 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. > > On Mon, Sep 16, 2019 at 10:33 AM Joe Watkins <krakjoe@gmail.com> wrote: > > > 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 >
  107163
September 16, 2019 10:22 pierre.php@gmail.com (Pierre Joye)
On Mon, Sep 16, 2019 at 5: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. > > 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
  107164
September 16, 2019 11:01 kenashkov@gmail.com (Vesselin Kenashkov)
On Mon, Sep 16, 2019 at 1:23 PM Pierre Joye php@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. 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
September 16, 2019 13:35 chasepeeler@gmail.com (Chase Peeler)
On Mon, Sep 16, 2019 at 7:01 AM Vesselin Kenashkov <kenashkov@gmail.com>
wrote:

> On Mon, Sep 16, 2019 at 1:23 PM Pierre Joye php@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
  107165
September 16, 2019 12:41 zeev@php.net (Zeev Suraski)
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