1215 1033 1567 1307 1858 1508 1501 1919 1357 1568 1045 1701 1126 1376 1704 1421 1774 1886 1396 1644 1011 1597 1464 1840 1089 1374 1083 1312 1039 1644 1966 1651 1736 1417 1268 1828 1886 1378 1913 1747 1208 1351 1672 1419 1428 1475 1813 1307 1244 1053 1576 1725 1721 1612 1134 1097 1149 1303 1610 1500 1380 1196 1627 1492 1181 1668 1594 1045 1123 1850 1343 1941 1497 1255 1467 1322 1682 1982 1946 1759 1844 1710 1053 1368 1675 1891 1722 1193 1909 1231 1211 1146 1294 1780 1800 1105 1660 1118 1808 re: re: A letter to the PHP team | PHPnews.io

PHPnews.io

re: re: A letter to the PHP team

Written by Stitcher.io / Original link on Aug. 28, 2019

Thanks you Joe for taking the time to reply to my letter, I really appreciate it! I'll be happy to reply here.

Your reply started by addressing the P++ shenanigans:

A lot of the discussion is based on an assertion made during the P++ discussion that there are two camps of developers

As a matter of fact, I started writing my letter before the whole P++ galaxy discussion. Life got in the way though (my son was born at the beginning of August), which is why it took almost a month to publish it.

I just wanted to make clear that I already had many thoughts on the topic before P++ was ever mentioned.

You can tell by looking at the history of RFCs that these factions do not in fact exist

Whether we call it factions or not, if you take a look at recent RFCs, they have almost always gone off topic for to discuss the future of PHP on a broader scale. Sure there might only a few people, but loud voices are heard nevertheless.

A few examples:

This is how most of these discussion go:

The rules were written many years ago - arguably for a totally different, pre social coding world - we mostly do a good job of following the rules as they are written.

I think you addressed the essence of the problem: the way PHP internals work is outdated and inefficient in these modern times.

It's important to point out that the rules are not exhaustive, a lot of how we behave is determined by convention. You can argue against this and say that we should try to exhaustively enumerate every possible action

I'd argue we need a sensible and modern day rule set, which can be flexible.

Recently an RFC was conducted to deprecate and remove short PHP tag syntax

While I do have my opinions on maintaining backwards compatibility — which I addressed in the first part of my letter — I think the most important thing to take away from the short syntax RFC is that the process is clearly broken, and needs fixing.

What we have here is a failing of our processes and nothing more. I and likely others are considering how we might avoid this very same failure in the future. It seems desirable at this time to introduce a formal deprecation policy, this both achieves the goal of avoiding this very same failure, and can potentially increase confidence when it comes to adopting new versions of PHP.

Glad we're on the same page on this one, and I know from your comments on internals that you're also looking for a balanced solution. My question is whether this is possible within the current system. It feels like we're going around in circles and very little progress is made.

First, for the sake of clarity. You must be careful how you determine something to be controversial. Loud, is not the same as controversial

That's true, though a few loud voices can impact the development of PHP significantly. There aren't many core contributors, and they have to spend a lot of time reading and replying through the same discussions. I try to keep up-to-date with the internals list myself, so I know this is an exhaustive task.

The time and effort it takes to change our processes is considerable, and only becomes a priority when it's obvious that our processes are failing, or have the potential to fail and do damage.

I think PHP is only slowly evolving because there's so much needless discussions happening over and over again, I'd call that a failing process.

I'm sure that you have a sample of data that shows you this, or you surely wouldn't have made this claim.

Yes, I linked some recent examples previously.

It's a matter of fact that some people can't seem to behave themselves on the internet, while I'm sure (read: must believe) they are reasonable people in real life. These people make themselves obvious very quickly and prove they have nothing much to say.

I think some kind of moderation would be in place, as these people keep coming back, and there's no way to stop them. This is where a mailing list just doesn't suffice.

I can't argue that mailing lists are a good way to communicate, but it's what we have. However, it's not all we have:

True, though the channels you list still don't seem to bridge the gap between core- and userland developers. This is evident by the amount of userland developers voicing their opinions on all kinds of social media. I think a public forum is the way to go here.

This is regularly mentioned, and I think I'll be the first one to point out that to the extent which that is true, it is the communities fault.

There are two groups here:

The wiki isn't very clear on this:

People with php.net VCS accounts that have contributed code to PHP

Representatives from the PHP community, that will be chosen by those with php.net VCS accounts Lead developers of PHP based projects (frameworks, cms, tools, etc.) regular participant of internals discussions

Personally, I think of myself in this second group, though it's unclear to me whether my perception is correct. And I can think of several other developers who would be an accurate representation of the PHP community.

Should I ask? As a matter of fact, I did ask a core member personally, but didn't get a reply. Should I ask this question on the internals list? I'm unsure.

This is again an example of failing communication between core- and userland developers. There's a barrier that's perceived as uncrossable.

Now I'm not saying there is an actual barrier, I just say that it's perceived by many userland developers this way, myself included.

Once again, thank you very much for your reply Joe. I highly appreciate it and am looking forward to read your comments on mine.

Kind regards
Brent

stitcher.io

« Guest posts - A letter to the PHP team »