Bearings

Fig 1. Some Bearings

There is a lot of talk about the direction of PHP as a language, there have been discussions on internals and open letters from community bloggers ...

I think, actually, there is rather a lot of confusion in the air, and so I'm seeking to cleanse that air with this post.

Factions

A lot of the discussion is based on an assertion made during the P++ discussion that there are two camps of developers, one that prefers the language to retain as much of its dynamic nature as it has today, and another who would like to move away from the historically dynamic nature of PHP towards a more strict language.

This assertion is palpably false, and I have seen almost every internals developer that has been involved in the conversation recently point out this falsehood.

You can tell by looking at the history of RFCs that these factions do not in fact exist, you can tell that in every case, a majority of people voted for features that make PHP more strict (importantly, as an opt-in feature), a majority introduced types, a majority does everything. We move forward together, or not at all.

When you take away the problem of imaginary factions, a lot of the discussions going on seem to have no basis at all, including the P++ discussion itself.

Failings

Like many open source projects, PHP internals have a bunch of processes we are supposed to follow for fixing bugs and introducing features into the language.

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.

Recently I pushed through some changes to the rules to make sure that there is always sufficient voting time and majority (2/3) support for a change before it's accepted.

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 a contributor might take and document exactly how they should take it ... it would be a pretty silly argument, but you could make it ...

Recently an RFC was conducted to deprecate and remove short PHP tag syntax, it is unlucky that the contributor that conducted the RFC was new to internals, and that they weren't aware of convention.

Conventionally, when it comes to deprecation and removal of features, we tend to decide if we're going to deprecate something, and removal follows if we accept that the feature needs to be deprecated. Deprecation does not disable a feature, it raises a deprecation notice only.

Unfortunately, without awareness of this convention, the conductor of the RFC created a vote that asked separately if we should deprecate and disable short tags in 7.4 (to which the answer was yes), and if we should remove short tags in a 8.0 (to which the answer was yes).

This result is in part the basis for the faction claim: It looks like there are a bunch of us that would prefer to just remove cruft, and balls to the developer, and a bunch of us that want to take a more gentle path and deprecate things before removal, or not deprecate them at all.

In actual fact, everyone was likely confused about the questions being asked, and the vote should have been stopped before it reached completion the first time round.

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.

Future

You can't stand on the ocean shore and grab a cup full of water and conclude that there is nothing more to find in the ocean than there is in the cup.

You can't look at the last two or three discussions and make any conclusions based upon them, and formulating plans based on those conclusions makes absolutely no sense whatsoever.

As already mentioned, you can look at the broad history of PHP as recorded by RFC's and make determinations about where PHP might head in the future, but taking a small sample can't work.

Response

Now, I want to reply to some specific points raised in the open letter to internals ...

Internals have been discussing voting mechanics and what to do with controversial RFCs for months now.

Shouldn't we start looking at how other communities do this? For sure PHP can't be the only open source language out there?

First, for the sake of clarity. You must be careful how you determine something to be controversial. Loud, is not the same as controversial. Attracting a lot of attention from two or three contributors does not make a controversial topic, it makes loud contributors.

Whatever, it's a fact that we've been concerned with our processes and have made some changes - It's somewhere between difficult and impossible to call anything with 2/3 majority support garnered over a period of at least two weeks controversial.

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.

PHP isn't special in this regard, while the details vary, all open source projects roughly work the same. They determine a set of rules for them which everyone has to follow which includes a workflow, everyone tries to follow it, and when it's broken it gets fixed.

the same discussions happen over and over again on a weekly or monthly basis without any progress

I'm sure that you have a sample of data that shows you this, or you surely wouldn't have made this claim. But history disagrees with you, almost all of the big features introduced into PHP in recent years have gone through several iterations before being accepted, for scalar types it was 5 iterations I think. With every iteration, with every "no", progress is being made.

When you open an RFC you are essentially asking "Is solution X the best way to approach problem Y?". The answer yes, is just as valid as the answer no. It just so happens that the RFC should come prepared with solution X, so the answer yes seems like the better and it certainly is the faster route.

people are personally attacking others regularly

I dispute the use of the word regularly, but it occurs to me that my ability to dispute it may be down to my use of spam filters, and my method of subscription.

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. Like any form of communication you are free to block that which you do not want to hear, you should not be afraid to do that if it increases your own happiness.

It's common now, even among seasoned contributors, to use the very excellent externals.io interface to consume internals mailing lists, and I'm not sure if this has a block/silence feature, maybe the owners could be approached about that ...

an insignificant RFC takes months of discussion and requires a re-vote after being accepted

I think I've covered this under Failings ...

 there aren't any good ways to share constructive feedback apart from the big mailing list

 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:

• You can email any contributor you like
• You can get involved in the conversation on github pull requests
• You can go to #php.pecl on IRC
• You can scream out of your office window - may not work as form of communication, but may relieve stress.

Genuinely constructive feedback will be well received no matter the method of delivery, and no matter how much noise the form of communication seems to carry with its signal.

There are several windows on PHP development, and internals is only one ... There is nothing wrong with approaching a smaller group of developers by email, or in IRC, or on Stackoverflow, so that you can further formulate your feedback with the input of other internals developers before sending to internals for mass consumption. Of course it's not obvious, but many of us operate like this. It's perfectly healthy, there are discussions going on all the time, everywhere internals developers gather.

the group of voters doesn't seem to be an accurate representation the actual PHP community

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.

It takes hardly any effort to earn yourself a voice as a voting internals contributor, you don't need to know C, you don't need to spend hours and hours every day working for free, you have to expend hardly any effort.

You surely want voters to have earned a vote, to somehow have a vested interest in the future of PHP. They are the people that have votes, I fail to see the problem.

If you're going to make the argument that not everyone has time to find a way to contribute to PHP, but they still deserve a voice, then you have to consider that if they have no time to contribute to earn the voice, they have no time to contribute to exercise it responsibly.

Voting takes more time than clicking yes or no, participating in one vote, any vote, is going to take more time than it takes to earn the voice.

Having said all that, there are still provisions to give voting powers to representatives from the PHP community (lead framework devs and such) who otherwise do not contribute to internals, and some such voters exist. If you want to say there are not enough such representatives, then I want to ask what more can we do than make the provision ?

If there are representatives in the community who want to engage in internals but don't have a vote, then they need to make this known ... we can only make the provision.


Peace out, phomies :)

Contriflossary

Regarding contribution to open source projects

The following scenario has been played out countless times, by a large number of [first time] contributors, to a large number of OSS projects:

• Find OSS project we love
• Attempt to navigate [source of] project
• Find this confusing
• Decide that there needs to be some "cleanup"
• Start making pull requests to cleanup [the source code]
• Pull requests are ignored, refused, or argued against
• Dismay

Most of the time, we quickly get a feel for the kind of pull requests that will be accepted, everybody moves on ...

But I wonder if they move on before putting any effort into explaining why this type of contribution is not always met with jumps for joy ...

I wonder if we can't say some things about all open source projects, that might guide new contributors to making the kind of contributions that have a good chance of being accepted. Perhaps, more importantly, making contributions in such a way that the (new) contributor becomes an asset for the project.

Communications

Communicating with a group of people at once, often about complicated technical matters, is not an easy thing, no matter the calibre of the programmer.

The following sections will seek to provide guidance regarding communications with existing contributing members of a project.

Signal to Noise

Contributing members of a project generally have a steady signal to noise ratio, that's to say, on a yearly (or quarterly, whatever) basis, they make about the same amount of noise, as they do contribute to progress. The ratio varies, depending on the contributor, but steadiness makes for normality, so typically we all get used to even the loudest contributors.

New contributors on the other hand, if nothing else than by virtue of the fact that they have more questions to ask than anybody else, tend to have an unsteady signal to noise ratio, and because the entities you are dealing with are human, this simply annoys them.

The people being annoyed, they very well remember being just as annoying as you are being, so don't take it to heart ...

But maybe there are some things you can do as a new contributor to try and keep a steady ratio ...

Mental Metabolism

New contributors are in learning mode, no matter how familiar they are with the subject matter, language, or patterns used in the project.

In learning mode, we tend to ask as many questions as occur to us, and seek answers as quickly as possible.

This tends to result in noisy communications: A thing to consider is that for every communication you might be sending notification to every subscriber to the medium, be it a github repository, mailing list, forum, or whatever.

Unless you are providing a patch for a life support system and lives are in danger, there is absolutely nothing that can't wait 24 hours.

By waiting a day between your communications, you are affording other contributors time to have their say (and possibly answer questions before you have had the opportunity to ask them). You are also providing yourself much more thinking time, possibly increasing the quality of your communication, and certainly reducing noise.

O(1) Communications

New contributions tend to garner responses or input from several sources, and having waited 24 hours since your last communication, you might have a pile of communications to respond to.

You can further reduce noise levels by responding to everybody at once, don't be afraid to tag people, segment, or otherwise format communications to achieve this.

Once you have the response for the day written out, you might try to compress it by finding overlap, you might even try to preempt what will happen next and try to provide answers to the coming questions in advance.

Source of Truth

Healthy projects tend to develop experts that don't necessarily have any involvement in contributing directly to the project: There are many many more Ruby experts than there are Ruby contributors, mutatis mutandis, the same is true for any project you like. These experts tend to be available outside of official channels, sometimes in groups, sometimes even in realtime.

Let opening an issue, pull request, or otherwise sending "official" communications be a last resort. Realise that the project you are dealing with is never the only source of truth, and that by finding other sources you can further and greatly reduce your noise level.

Choosing Battles

Be ready to gracefully walk away from any contribution or idea you had, be ready before you send your first communication to just be wrong.

Begin wrong is fine, that's how we learn ... It's sometimes hard to see that in the moment though, and find ourselves fighting tooth and nail for what we think is correct.

Realise that your first contributions are not likely to be your most important. You're dealing with humans, and if you make a lot of noise at an early stage, your voice will carry less weight later on.

The Pull Request

Whether communication should precede a pull request is sometimes determined by the rules of the project.

If you are making this decision, then consider how well the project deals with and responds to pull requests. 

If there seems to be evidence that the project struggles to deal with pull requests and if there is a channel for communications other than the channel opened with the pull request, consider communicating before opening a pull request.

Cost and Value

A pull request must result in a net gain for the project.

There are so many ways to achieve a gain that it would be pointless to try to enumerate them. The most common path to a loss is as a result of miscalculation of cost.

As the author of the pull request, you might want to say that the cost associated is whatever it cost you to write the pull request.

But that's not the only cost associated, here's a better starting place for a list of costs:

• The time it took you to write the pull request
• The time it's going to take someone, or some people to review the pull request
• The time it's going to take someone to merge the pull request
• The time it's going to take someone, or some people to document your changes
• The time it's going to cost anyone familiar with whatever you are changing

All of this, before the correctness of the pull request even matters. 

Of course, correctness does matter, as well as the content of the pull request ... In some cases, a pull request will have an ongoing, or ongoing costs associated with it. 

Generally, if that ongoing cost is going to be incurred by humans we call it technical debt.

Generally, if that ongoing cost is going to be incurred by the machines executing the code, we refer to it as implementation complexity, or some other fancy term.

These costs hard to quantify, and there is likely disparity between your method of calculating these costs and the methods of existing contributors.

The value your pull request provides must exceed the sum of these costs (as calculated by existing contributors) to be worthwhile, and you should be utterly confident that it does that before you open the pull request.

Final Words

Don't let anything, including the words herein, deter you from your goal of becoming a contributor. 

Achieving your goal will be your reward ...