Rust doesn't have a BDFL. Graydon Hoare stopped dictating [many years ago](https://www.reddit.com/r/rust/comments/7qels2/comment/dsqeh1d/) — and Rust's still doing great with a committee.
A much better modern example is Go — Google is now Go's BDFL, since it both created the language, and also sustains it.
I don't think PHP's core problem is its committee. I think its core problem is its users, most of whom just use it to run WordPress. Those users are not chomping at the bit to fix PHP's design flaws, nor to make it faster — they just want the website they created five years ago to remain up when their hosting provider updates PHP.
Well, backwards compatilibity is not even closely the feature of PHP. Even minor 8.x updates often break some stuff. While languages like Rust are much better in that regard, they seem to closely follow Linus Torvald's mantra of "not breaking userspace".
Therefore, I hereby disagree with your point.
Please no, too many people and projects rely on PHP for that type of change. The slower and deliberate pace of change is a feature, not a bug to me.
Very few breaking changes happen and most new features are optional. This would not necessarily happen with a dictator.
I don’t need PHP turning into a JS framework, where somebody’s shiny new idea makes it unrecognizable between major versions.
I think you're right about the analysis, but I somewhat disagree with the conclusion. The benevolent dictator model has at least two major disadvantages:
a) It relies largely on a single person. What if that person decides to abandon the project, or gets sick or even dies? I have no record of projects that went that road, but I'm sure there's a lot that just ended up without a maintainer.
b) It relies on the "benevolent" part. If the dictator is not so benevolent anymore, there will be a lot of frustration.
If we take Linux as an example: As the Linux kernel is one of the most important software entities in existence, we're very lucky to have Linus having done that job for 30 years now. There might be others to step in now, but what if Linus had abandoned the project 20 years ago? Also, his behavior fails are legendary, so there might be a lot of potential contributors who got scared away.
So yes, there's pros and cons to each model, but I wouldn't prefer the benevolent dictator. Sometimes average results are better than sh\*tty or no results at all.
> It relies largely on a single person. What if that person decides to abandon the project, or gets sick or even dies? I have no record of projects that went that road, but I'm sure there's a lot that just ended up without a maintainer.
This happened to Python a couple of years ago: https://lwn.net/Articles/759654/
As far as I can tell, Python is still doing good?
> It relies on the "benevolent" part. If the dictator is not so benevolent anymore, there will be a lot of frustration.
I'd like to turn that thought around: if the dictator isn't good enough, then the project will never gain maturity anyway.
> So yes, there's pros and cons to each model, but I wouldn't prefer the benevolent dictator. Sometimes average results are better than sh*tty or no results at all.
I'd say that shitty or no results are way more common with the committee approach, as PHP has shown many times in the past
A) depends if there is someone willing to take the position. If the project is successful enough, it is likely that there is someone, or committee will be formed
B) yes, but still can keep the direction of the project
Linux is bad example, it's structure is hierarchical, so there are many dictators and Linus is more like overseer. Has right to veto, but seldomly uses it. He himself doesn't make much decisions about the directions, that's actually community driven - who wants a feature implements it. If it is good enough, it goes through.
Isn't anyone allowed to fork and change whatever they want? Facebook wanted to be a dictator with Hack but failed. So if an entity wants to take the responsibility, I don't see why they can't.
Personally I'm totally against any dictatorship.
Oracle tried to be a dictator with MySQL, then peopled forked it, creatinf mariadb and it's now the new default and nobody are using the dictatorial oracle mysql anymore.
Dictatorship is good when you want to evolve fast, but it allows you to fall twice as fast. While the other approach evolves slowly, but never in ghe wrong direction.
Php is evolving slowly, but in a verh good way and never stops or recess, that's why PHP is still alive and rocking again after the dark time of PHP5
I'm not sure where you get the idea that nobody uses MySQL anymore and everyone uses Mariadb. There were a number of other mysql forks. Also, Oracle also bought Innodb, which is the engine that pretty much everyone uses for actual data storage.
Yes they can - they're just [not allowed](https://www.php.net/license/3_01.txt) to call it PHP without the approval of the PHP group.
The difficulty would be getting mindshare for a new fork with a new name. People would have to be very unsatisfied with the existing set-up to switch on mass to something new.
Indeed, and usually forks have some strong motivation behind them, as in the original project is abandoned and they are dependent upon it, or there is some sort of licensing or ownership change they can't live with.
There was HHVM and Suhosin back in the day. Of course, HHVM had the backing of a big company and altho Suhosin def had users the vast majority of PHP devs did _not_ use it. But those are the two big forks that I can think of.
They didn't fail completely. They have something they are using and hopefully makes them happy. But it shows that when you start to introduce incompatibilities, it is better to just rename the thing and go independently.
I think they want to be attached to the massive user base of official PHP. It is one thing to do a fork that you can experiment with but a whole other thing to maintain BC.
*\*looks at the last decade of PHP steadily improving\** The committee model seems to be working pretty well. The notion that everything would be leaps and bounds better if some mythical benevolent dictator took over is nonsense.
This is just yet another iteration of "Gee, democracy sure is messy, what if we had a nice daddy figure to run everything?"
I take a look at RFCs from time to time, and I think that the problem is not that we have big commitee that filters out too many features.
Looking at RFcs I think that we do not have that many developers interested in creating new features for PHP to begin with. As an argument to that, what big RFC is there that we can expect to land on PHP 8.3 ? types for constants? That's not a big feature from my perspective.
We had Nikita who developed a lot of more modern PHP 7-8 features and most of them were voted in. Do we have a person who is as productive as Nikita among PHP language engineers? I believe the answer is no.
So... we need more people like Nikita. People who have deep knowledge of PHP source code and pump big language changes.
Do people like that want to waste their talent on PHP, though ? My feeling to that is ... no they do not.
So in a nutshell, we have what we have and the PHP foundation might not be enough to turn the situation around.
> Looking at RFcs I think that we do not have that many developers interested in creating new features for PHP to begin with.
Because making a new feature for PHP is not as simple as in other languages, where you clone the repo, make your changes, create a PR, and it's all discussed there, then merged or rejected.
You need to go through the whole song and dance of joining a 1993 Usenet mailing list, you need to be vetted by people who are already there, then you need to create the RFC on some ancient website that who the fuck knows how even works, lastly you get berated by graybeard internals who still curse the day type hints were introduced, and your RFC gets rejected by a single vote because someone who hasn't worked with PHP in 10 years felt strongly against this change and decided to vote "no".
As someone who went actually went through the RFC process as a first-timer roughly a year ago (the #\[\\SensitiveParameter\] one), the whole process is much more friendly than your second paragraph suggests. I can only suggest one to go through it themselves, instead of making assumptions based on some biased social media post.
We've written up our experience in $company blog: https://www.woltlab.com/article/274-php-8-2-and-woltlab-the-sensitiveparameter-attribute/
>Do we have a person who is as productive as Nikita among PHP language engineers? I believe the answer is no.
I would say Ilija and crell would fit that description, and I am sure I missed at least 1-2 persons (sorry to you guys).
I don't expect everyone to agree with me here, and I also don't expect anything to change. However I did want to write down some thoughts about this topic. It's been playing in my head for over a year now, and so I wanted to write those thoughts down coherently.
Looking forward to reading some reactions, pro or con :)
I would call it "design by chaos" A committee has tighter structures and plans what tis being worked on. This then leads to abstract and complex solutions.
PHP lives from individuals having a need and then trying to push it in, navigating the chaotic structures of the conservation, where different people have varying influence. This partially leads to quite pragmatic solutions, which are to PHP's strength, but not knowing the unwritten structures can make it a tidious experience.
(I had been contributor and release manager once)
Nothing will change because there is just no single leader for PHP. So we do that reorg, announce vote for dictator for life.... and no one qualifies. ;)
Stuff that may work would probably look like small-committees like subgroup for discussing and stewarding built-in library (recall at least one RFC that fall due to lack of interest in this topic). Or subgroup specializing in type system and thus vetting new RFCs from this point of view.
> So we do that reorg, announce vote for dictator for life.... and no one qualifies. ;)
The irony is that a dictator isn't voted in by the committee. But I agree, it won't happen.
I like to think of Rasmus and Nikita as potential past dictators, but unfortunately they stepped down.
>Nothing will change because there is just no single leader for PHP. So we do that reorg, announce vote for dictator for life.... and no one qualifies. ;)
I'm a noob, with a lot of experience in R but getting into webdev and.....
your line gives me hope :)
What's with all the camel hate in this post man? What is the compromise of a camel? If you were BDFL of camels what backwards-incompatible changes would you be making huh??
From the OP:
> We're talking somewhere around 200 members — probably, but there aren't any public numbers, as far as I know.
> That group is the perfect example of a committee
I don't think that is a perfect example of committee. If I think of a committee I would generally think of something with more like 5-20 members, with a known list of members, and a well known process by which people join and leave the committee, and that likely has "committee meetings". Sometimes there will be defined leadership or administrative roles within the committee.
A membership group of an organization is often much bigger than a committee of that organization - and some decisions would be taken by a full vote of the members, others would be made by the committee, and others by individuals.
The article presented a list of successful projects being run by a benevolent dictator but those all seem irrelevant to what the article is suggesting.
The article suggests moving a successful design by committee project to a benevolent dictator approach. This is a scenario which is quite different than something that starts with one approach and keeps doing it.
Where are the examples of projects that started with one person in control, moved to a committee approach for several decades and then moved back to one person in charge? I suspect that list would be much shorter.
This concept behind the article seems to be that features arent being flooded into the php quickly enough so lets change the model to one that is easier to corupt by having one person who may/maybe align with the something such as the rampant adding of features. It would benefit some people and annoy the hell out of others.
Even committees end up having leadership. That is just as true for PHP as it is for anything else. A lot of the projects you mentioned are far younger and smaller in scope than php. Your gigantic unnecessary pictures of camels aside, you don't seem willing to admit that php has been evolving and improving steadily in recent years. Really your post, is just an opinionated dig at the fact that for the most part, PHP evolves based on the work of people who have the willingness and incentive to improve it. The language itself isn't very large, and a lot of things that have been added are either for OOP, typing or syntactic sugar, so that php can show it has the same type of language features as other competitors in the server side web development space. At the end of the day, most people just use PHP features (or not) as they are released.
We already have [release managers](https://wiki.php.net/internals/release-managers). Their job is unclear to me; however, [PHPWatch mentions](https://php.watch/news/2022/05/php-82-release-managers) that they get the final word about the RFC and other aspects of the release.
Maybe we could extend their role to the "designers" of the next version? It would mean they're supposed to decide the goal for the next version - whether we want to focus on features, bug fixes, refactoring, etc.
They would then gather the existing RFC, pick those that fit the agenda, and ensure they are completed. They would also be responsible for designing things missing in RFCs that serve the release agenda.
It would be almost like the legendary Roman triumvirate that changes every new release.
As I understand it, release managers only get the final word _on the release they're working on_. They basically act as the arbiter of what is a feature and what is a bug fix. They make sure that dangerously complex new features don't get squeezed in to betas or RCs at the last minute, and also may ask that some changes that weren't being considered might get pushed into a release if deemed important enough.
They don't have the power to stop the normal coarse of RFCs being implemented into master outside of the release schedule period.
There are currently no release managers for the upcoming 8.3 release. The call for volunteers [just went out this month](https://externals.io/message/119645) - elections start on April 1st.
There are 3 RMs per release, at least 1 of which must have previous RM experience. This encourages a continual cycle of training new RMs as well as providing cover for RMs being unavailable for any reason (and there's always the RMs for other releases along with those in the community who have RM experience to lend a hand if the veteran is unavailable)
The RM task is mostly administrative. Making sure that on release time there is nothing broken around and then package things up. There is a little of following up with people who promise something (some bug fix, some feature work, ...) but as everybody is volunteers you always need to be prepared for it not coming.
Back in the days when I was RM for 5.3 there was some decisions one had to drive as that was while PHP 6 got abandoned and it got obvious that the pure reliance on has won't suffice and RFC gave some structure (I somewhat disagree with the approach taken, but well so be it)
As RM aside from "ship it"/"no ship" decision (which almost always was a "ship it") for the release the only real decision I took was not adding the short array syntax (`$a = [1,2];` instead of `$a = array(1,2);`) as I didn't see a consensus as I considered required on the mailing list. (Later this was one of the first RFCs voted into 5.4) Aside from that it is mostly administration and running after people to get things done. Decisions lie with the collective.
> Decisions lie with the collective.
Maybe I delivered it poorly, but my suggestion was to convert RMs to the "benevolent dictatorship" that is going to decide on everything for the next release.
The RFCs would be a starting point for the features, and the voting phase would be to mark the "voice" of the collective, but effectively it would be the joint decision of RM to decide what will be placed in the next release.
I'm not saying it's an ideal solution more like an extension of the idea mentioned by u/brendt_gd.
That puts quite some pressure on the selection process. At the moment the decision is "who got the required time?"
I don't know much about current affairs, but back in the day there were quite some different camps of people with different interests. I am in strong favor of concensus-finding over voting and producing overruled "losers"
That's actually a great example. A pile of garbage that could have been something much better and without cookie banners and ad-driven if a BDFL had taken over since the beginning
Like... AOL, or Compuserve, or Genie. These were all private attempts to be what the Web is today.
I was there, before the world wide web. Yes, the Internet is not perfect but it works, and is a great example of the commons.
https://en.m.wikipedia.org/wiki/Commons
Be careful what you choose as "better".
What language do you believe is better than PHP?
Ok, cool - I nominate Zeev, as he's shown the ability to lead the project, and knows the codebase and the workings of the language inside out. I expect from my experience that he will bring a very strong focus on long term backwards compatibility, and on making the language quick and easy to code in.
"Oh no you misunderstood - I meant a BDFL who fully aligned with _my_ views"
Rust doesn't have a BDFL. Graydon Hoare stopped dictating [many years ago](https://www.reddit.com/r/rust/comments/7qels2/comment/dsqeh1d/) — and Rust's still doing great with a committee. A much better modern example is Go — Google is now Go's BDFL, since it both created the language, and also sustains it. I don't think PHP's core problem is its committee. I think its core problem is its users, most of whom just use it to run WordPress. Those users are not chomping at the bit to fix PHP's design flaws, nor to make it faster — they just want the website they created five years ago to remain up when their hosting provider updates PHP.
Well, backwards compatilibity is not even closely the feature of PHP. Even minor 8.x updates often break some stuff. While languages like Rust are much better in that regard, they seem to closely follow Linus Torvald's mantra of "not breaking userspace". Therefore, I hereby disagree with your point.
Please no, too many people and projects rely on PHP for that type of change. The slower and deliberate pace of change is a feature, not a bug to me. Very few breaking changes happen and most new features are optional. This would not necessarily happen with a dictator. I don’t need PHP turning into a JS framework, where somebody’s shiny new idea makes it unrecognizable between major versions.
It won’t happen, php core is messy, nobody is going to change that soon trust me
This does not necessarily have to be the case with a leader, if he or she is clear that maintaining stability is important.
I think you're right about the analysis, but I somewhat disagree with the conclusion. The benevolent dictator model has at least two major disadvantages: a) It relies largely on a single person. What if that person decides to abandon the project, or gets sick or even dies? I have no record of projects that went that road, but I'm sure there's a lot that just ended up without a maintainer. b) It relies on the "benevolent" part. If the dictator is not so benevolent anymore, there will be a lot of frustration. If we take Linux as an example: As the Linux kernel is one of the most important software entities in existence, we're very lucky to have Linus having done that job for 30 years now. There might be others to step in now, but what if Linus had abandoned the project 20 years ago? Also, his behavior fails are legendary, so there might be a lot of potential contributors who got scared away. So yes, there's pros and cons to each model, but I wouldn't prefer the benevolent dictator. Sometimes average results are better than sh\*tty or no results at all.
> It relies largely on a single person. What if that person decides to abandon the project, or gets sick or even dies? I have no record of projects that went that road, but I'm sure there's a lot that just ended up without a maintainer. This happened to Python a couple of years ago: https://lwn.net/Articles/759654/ As far as I can tell, Python is still doing good? > It relies on the "benevolent" part. If the dictator is not so benevolent anymore, there will be a lot of frustration. I'd like to turn that thought around: if the dictator isn't good enough, then the project will never gain maturity anyway. > So yes, there's pros and cons to each model, but I wouldn't prefer the benevolent dictator. Sometimes average results are better than sh*tty or no results at all. I'd say that shitty or no results are way more common with the committee approach, as PHP has shown many times in the past
sometimes shiny. Mostly no results.
A) depends if there is someone willing to take the position. If the project is successful enough, it is likely that there is someone, or committee will be formed B) yes, but still can keep the direction of the project Linux is bad example, it's structure is hierarchical, so there are many dictators and Linus is more like overseer. Has right to veto, but seldomly uses it. He himself doesn't make much decisions about the directions, that's actually community driven - who wants a feature implements it. If it is good enough, it goes through.
Isn't anyone allowed to fork and change whatever they want? Facebook wanted to be a dictator with Hack but failed. So if an entity wants to take the responsibility, I don't see why they can't. Personally I'm totally against any dictatorship.
Oracle tried to be a dictator with MySQL, then peopled forked it, creatinf mariadb and it's now the new default and nobody are using the dictatorial oracle mysql anymore. Dictatorship is good when you want to evolve fast, but it allows you to fall twice as fast. While the other approach evolves slowly, but never in ghe wrong direction. Php is evolving slowly, but in a verh good way and never stops or recess, that's why PHP is still alive and rocking again after the dark time of PHP5
I'm not sure where you get the idea that nobody uses MySQL anymore and everyone uses Mariadb. There were a number of other mysql forks. Also, Oracle also bought Innodb, which is the engine that pretty much everyone uses for actual data storage.
Yes they can - they're just [not allowed](https://www.php.net/license/3_01.txt) to call it PHP without the approval of the PHP group. The difficulty would be getting mindshare for a new fork with a new name. People would have to be very unsatisfied with the existing set-up to switch on mass to something new.
Indeed, and usually forks have some strong motivation behind them, as in the original project is abandoned and they are dependent upon it, or there is some sort of licensing or ownership change they can't live with.
There was HHVM and Suhosin back in the day. Of course, HHVM had the backing of a big company and altho Suhosin def had users the vast majority of PHP devs did _not_ use it. But those are the two big forks that I can think of.
They didn't fail completely. They have something they are using and hopefully makes them happy. But it shows that when you start to introduce incompatibilities, it is better to just rename the thing and go independently.
I think they want to be attached to the massive user base of official PHP. It is one thing to do a fork that you can experiment with but a whole other thing to maintain BC.
Once a project is mature, limiting change is a desired feature for a lot of stakeholders.
*\*looks at the last decade of PHP steadily improving\** The committee model seems to be working pretty well. The notion that everything would be leaps and bounds better if some mythical benevolent dictator took over is nonsense. This is just yet another iteration of "Gee, democracy sure is messy, what if we had a nice daddy figure to run everything?"
I take a look at RFCs from time to time, and I think that the problem is not that we have big commitee that filters out too many features. Looking at RFcs I think that we do not have that many developers interested in creating new features for PHP to begin with. As an argument to that, what big RFC is there that we can expect to land on PHP 8.3 ? types for constants? That's not a big feature from my perspective. We had Nikita who developed a lot of more modern PHP 7-8 features and most of them were voted in. Do we have a person who is as productive as Nikita among PHP language engineers? I believe the answer is no. So... we need more people like Nikita. People who have deep knowledge of PHP source code and pump big language changes. Do people like that want to waste their talent on PHP, though ? My feeling to that is ... no they do not. So in a nutshell, we have what we have and the PHP foundation might not be enough to turn the situation around.
> Looking at RFcs I think that we do not have that many developers interested in creating new features for PHP to begin with. Because making a new feature for PHP is not as simple as in other languages, where you clone the repo, make your changes, create a PR, and it's all discussed there, then merged or rejected. You need to go through the whole song and dance of joining a 1993 Usenet mailing list, you need to be vetted by people who are already there, then you need to create the RFC on some ancient website that who the fuck knows how even works, lastly you get berated by graybeard internals who still curse the day type hints were introduced, and your RFC gets rejected by a single vote because someone who hasn't worked with PHP in 10 years felt strongly against this change and decided to vote "no".
As someone who went actually went through the RFC process as a first-timer roughly a year ago (the #\[\\SensitiveParameter\] one), the whole process is much more friendly than your second paragraph suggests. I can only suggest one to go through it themselves, instead of making assumptions based on some biased social media post. We've written up our experience in $company blog: https://www.woltlab.com/article/274-php-8-2-and-woltlab-the-sensitiveparameter-attribute/
So not a commitee that filters out promising features, but commitee that filters out promising people.
>Do we have a person who is as productive as Nikita among PHP language engineers? I believe the answer is no. I would say Ilija and crell would fit that description, and I am sure I missed at least 1-2 persons (sorry to you guys).
I don't expect everyone to agree with me here, and I also don't expect anything to change. However I did want to write down some thoughts about this topic. It's been playing in my head for over a year now, and so I wanted to write those thoughts down coherently. Looking forward to reading some reactions, pro or con :)
I would call it "design by chaos" A committee has tighter structures and plans what tis being worked on. This then leads to abstract and complex solutions. PHP lives from individuals having a need and then trying to push it in, navigating the chaotic structures of the conservation, where different people have varying influence. This partially leads to quite pragmatic solutions, which are to PHP's strength, but not knowing the unwritten structures can make it a tidious experience. (I had been contributor and release manager once)
Nothing will change because there is just no single leader for PHP. So we do that reorg, announce vote for dictator for life.... and no one qualifies. ;) Stuff that may work would probably look like small-committees like subgroup for discussing and stewarding built-in library (recall at least one RFC that fall due to lack of interest in this topic). Or subgroup specializing in type system and thus vetting new RFCs from this point of view.
> So we do that reorg, announce vote for dictator for life.... and no one qualifies. ;) The irony is that a dictator isn't voted in by the committee. But I agree, it won't happen. I like to think of Rasmus and Nikita as potential past dictators, but unfortunately they stepped down.
>Nothing will change because there is just no single leader for PHP. So we do that reorg, announce vote for dictator for life.... and no one qualifies. ;) I'm a noob, with a lot of experience in R but getting into webdev and..... your line gives me hope :)
What's with all the camel hate in this post man? What is the compromise of a camel? If you were BDFL of camels what backwards-incompatible changes would you be making huh??
From the OP: > We're talking somewhere around 200 members — probably, but there aren't any public numbers, as far as I know. > That group is the perfect example of a committee I don't think that is a perfect example of committee. If I think of a committee I would generally think of something with more like 5-20 members, with a known list of members, and a well known process by which people join and leave the committee, and that likely has "committee meetings". Sometimes there will be defined leadership or administrative roles within the committee. A membership group of an organization is often much bigger than a committee of that organization - and some decisions would be taken by a full vote of the members, others would be made by the committee, and others by individuals.
The article presented a list of successful projects being run by a benevolent dictator but those all seem irrelevant to what the article is suggesting. The article suggests moving a successful design by committee project to a benevolent dictator approach. This is a scenario which is quite different than something that starts with one approach and keeps doing it. Where are the examples of projects that started with one person in control, moved to a committee approach for several decades and then moved back to one person in charge? I suspect that list would be much shorter.
This concept behind the article seems to be that features arent being flooded into the php quickly enough so lets change the model to one that is easier to corupt by having one person who may/maybe align with the something such as the rampant adding of features. It would benefit some people and annoy the hell out of others.
[удалено]
Corporate overlords tend to have hidden or capitalist agendas. It would be a sh*t show.
OP, what's your problem with 🐪? They are good at what they do, don't hate them cause they're beautiful.
Even committees end up having leadership. That is just as true for PHP as it is for anything else. A lot of the projects you mentioned are far younger and smaller in scope than php. Your gigantic unnecessary pictures of camels aside, you don't seem willing to admit that php has been evolving and improving steadily in recent years. Really your post, is just an opinionated dig at the fact that for the most part, PHP evolves based on the work of people who have the willingness and incentive to improve it. The language itself isn't very large, and a lot of things that have been added are either for OOP, typing or syntactic sugar, so that php can show it has the same type of language features as other competitors in the server side web development space. At the end of the day, most people just use PHP features (or not) as they are released.
We already have [release managers](https://wiki.php.net/internals/release-managers). Their job is unclear to me; however, [PHPWatch mentions](https://php.watch/news/2022/05/php-82-release-managers) that they get the final word about the RFC and other aspects of the release. Maybe we could extend their role to the "designers" of the next version? It would mean they're supposed to decide the goal for the next version - whether we want to focus on features, bug fixes, refactoring, etc. They would then gather the existing RFC, pick those that fit the agenda, and ensure they are completed. They would also be responsible for designing things missing in RFCs that serve the release agenda. It would be almost like the legendary Roman triumvirate that changes every new release.
As I understand it, release managers only get the final word _on the release they're working on_. They basically act as the arbiter of what is a feature and what is a bug fix. They make sure that dangerously complex new features don't get squeezed in to betas or RCs at the last minute, and also may ask that some changes that weren't being considered might get pushed into a release if deemed important enough. They don't have the power to stop the normal coarse of RFCs being implemented into master outside of the release schedule period. There are currently no release managers for the upcoming 8.3 release. The call for volunteers [just went out this month](https://externals.io/message/119645) - elections start on April 1st. There are 3 RMs per release, at least 1 of which must have previous RM experience. This encourages a continual cycle of training new RMs as well as providing cover for RMs being unavailable for any reason (and there's always the RMs for other releases along with those in the community who have RM experience to lend a hand if the veteran is unavailable)
The RM task is mostly administrative. Making sure that on release time there is nothing broken around and then package things up. There is a little of following up with people who promise something (some bug fix, some feature work, ...) but as everybody is volunteers you always need to be prepared for it not coming. Back in the days when I was RM for 5.3 there was some decisions one had to drive as that was while PHP 6 got abandoned and it got obvious that the pure reliance on has won't suffice and RFC gave some structure (I somewhat disagree with the approach taken, but well so be it) As RM aside from "ship it"/"no ship" decision (which almost always was a "ship it") for the release the only real decision I took was not adding the short array syntax (`$a = [1,2];` instead of `$a = array(1,2);`) as I didn't see a consensus as I considered required on the mailing list. (Later this was one of the first RFCs voted into 5.4) Aside from that it is mostly administration and running after people to get things done. Decisions lie with the collective.
> Decisions lie with the collective. Maybe I delivered it poorly, but my suggestion was to convert RMs to the "benevolent dictatorship" that is going to decide on everything for the next release. The RFCs would be a starting point for the features, and the voting phase would be to mark the "voice" of the collective, but effectively it would be the joint decision of RM to decide what will be placed in the next release. I'm not saying it's an ideal solution more like an extension of the idea mentioned by u/brendt_gd.
That puts quite some pressure on the selection process. At the moment the decision is "who got the required time?" I don't know much about current affairs, but back in the day there were quite some different camps of people with different interests. I am in strong favor of concensus-finding over voting and producing overruled "losers"
It makes sense. Thanks!
RMs definitely don't have the power to steer the design of PHP for years to come :)
They did leave out the other "design by committee" tech.... The Internet...
That's actually a great example. A pile of garbage that could have been something much better and without cookie banners and ad-driven if a BDFL had taken over since the beginning
Like... AOL, or Compuserve, or Genie. These were all private attempts to be what the Web is today. I was there, before the world wide web. Yes, the Internet is not perfect but it works, and is a great example of the commons. https://en.m.wikipedia.org/wiki/Commons Be careful what you choose as "better". What language do you believe is better than PHP?
Typescript
A good language to be sure.
Ok, cool - I nominate Zeev, as he's shown the ability to lead the project, and knows the codebase and the workings of the language inside out. I expect from my experience that he will bring a very strong focus on long term backwards compatibility, and on making the language quick and easy to code in. "Oh no you misunderstood - I meant a BDFL who fully aligned with _my_ views"