On Mon, Sep 16, 2019 at 1:18 PM Benjamin Eberlei <kont...@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
