Solving the PHP Internals Workflow

Posted: 2013-09-12
Category: PHP

On Monday I posted a tale of woe, which like any good tale had a moral at the end.

The moral was that while PHP internals has its troubles, the troubles are really being perpetuated by a small few, and there is a clear path to solving the problems.

The article seemed to resonate with a lot of people:

Time for another story.

I joined the PHP-FIG while the PSR-1 & PSR-2 votes were coming to a close, and as such I didn't have anything to do with their generation other than a bit of feedback on a few sentences.

PSR-3 came around while I was an active member and I had the chance to put in some feedback, which was tricky throughout a sea of bitching about - amongst other things - whether interfaces should be called FooInterface or Fooable. Seriously, that was about 60 emails alone.

I saw that conversation happening, and I was part of conversations about a Caching PSR, one for HTTP Clients (which then morphed into HTTP Messages) and a few other PSRs being discussed.

At the time things seemed great. The FIG was the wild-west and we were all doing our thing. The mailing list was modelled after internals, we were all throwing out our opinions, progress was made here and there and for a while things seemed ok. Every now and then a troll would pop up and derail the situation but we'd get him/her sorted out with some self-moderation and get on with the conversation eventually.

But then a year later only PSR-3 had made it out of the gate. HTTP was dead in the water, Caching was "nearly at a vote" for months, a new autoloader nearly got through but then was attacked with about 3 different alternative proposals at the 11th hour and all sorts of other madness.

It soon became incredibly clear that this approach would never work.

We needed a workflow, and so does PHP.

Right now the internals workflow is outlined on the How To Create A RFC. Newcomers are routed to an Oracle blog website to learn about the process:

If you're new to PHP core development, mail the "internals" mail list to judge interest before you start your RFC. If you get no reaction (this is likely) or positive reaction then create the RFC. Core PHP developers with karma will know when they can skip this step.

So, you're brand new to PHP and the process is you should post to internals then if no reaction is received then they should get going?

Problem #1: I got no reactions to my posts for a several weeks before I discovered there was just a bug in the mailing list system. How would somebody know if their idea is getting no feedback, or is quietly approved?

Problem #2: Despite the exact wording of the guide, it's commonly accepted that "An RFC without a patch is just noise". This has two further problems:

Problem #3: Don't know C? Go learn it, because we won't take you seriously otherwise.

Problem #4: Don't know the intricacies of the parser/serialiser/etc? Go learn it, because we won't take you seriously otherwise.

Something like the FIG workflow at this point would come into play quite nicely. We have the idea of a "Pre-Draft" proposal. This is just some file on the internet somewhere and has no relevance to anything. Somebody can put together as much information as they can and - even if its incomplete - find sponsors from within the FIG, one of which will bring start an Entrance Vote.

  • Anyone can propose a PSR.
  • If it passes the Entrance Vote we approve working on the idea.
  • You have people who know how to implement it available and interested.

When this Draft PSR is considered ready, it is brought to the mailing list for "Review". People go through it at this point - when it has some form, and is more ready that initial ideas. People ask a lot of questions, the meta document gets updated, FAQs are built and it stays there for two weeks to let anyone have a chance to give feedback.

Then after that two weeks it goes in for another vote. If it passes that vote it is then "Accepted", and we have a new PSR.

PHP Internals needs a workflow

While the exact same workflow would not directly work, something could definitely be put together that would benefit everyone.

Something we HAVE to do is get away from the "if you don't know C then fuck you" mindset.

I completely understand that ideas are cheap and implementations are hard. I've worked in startups long enough to know everyone has a million ideas everyday, many of which are shit, unrealistic, or wonderful but without an implementation are just words.

I'm not expecting anyone to say "oh good, you had a nice idea, let me go and spend 3 weeks coding that up for you.". What I am hoping is that we can get to a point where we can let self appointed working groups of 3+ come together to flesh out an idea, get some sort of "yes, we like this idea" stamp of approval from a majority, then focus on how it COULD be implemented before the time and effort goes into actually implementing it.

For example, the Named Parameter RFC contains reference to my syntax suggestions. Those syntax suggestions came from me (somebody who hasn't touched C since college) being interested in named parameters enough to put together a set of pros and cons of potential syntax options.

Is it not better than this research into potential syntaxes can go ahead (and people on the mailing list can potentially vote on a syntax) before somebody puts the time and effort into making a syntax?

Getting a stamp of approval BEFORE an implementation resolves a LOT of problems.

  • It will stop people wasting their time increasing the chances of repeat contributions.
  • It will stop the ego-attachment to their work, because "their baby" could be more in line with what the majority want before they get going.
  • It will ease the RFC process, as people have already obviously outlined an interest in the feature BEFORE we're getting to a chance to review the patch or vote.

PHP Internals could be AWESOME

Today was an explosive day on internals, most likely driven by a resounding agreement by many that things are currently not ok.

The request for the mailing list to be moved to a forum system was initially fought against hard, but has since evolved into a brilliant solution: improving the web interface for to handle threaded conversations and all handle actual conversation there, while still sending out posts to the mailing list - keeping the community in one location but removing yet another barrier to entry for smart new contributors.

People are complaining and suggesting that wont solve all the problems, but it will solve a LOT. Much like when talking to a zealous anti-gun control believer who says "Implementing background checks wont solve ALL gun crime ever!" I feel like saying "Of course it wont solve everything, but an X% improvement is an improvement, and there are no silver bullets.". #pun

Solving the interface will let a lot of people get involved, increase transparency and hopefully get some fresh blood into the group.

That is Step 1.

Step 2? Improve the workflow so that there is a clear path to getting a feature approved. In the FIG having such a regimented workflow has drastically improved the signal to noise ratio, and people have to read through far less content while knowing much more about what is happening in the group.

If anybody on the internals team would like to get in touch with me and flesh out a rock solid workflow much like I've done for the PHP-FIG please do so through my contact form, Twitter or whatever. We can easily make internals a useful productive place where everyone feels welcome, with a few little bylaws that everyone can enforce themselves.

We don't need leadership, we don't need a BDFL, we just need to stop arguing like we're in Mean Girls and get something useful done. A few rules can make that happen, and I'll be happy to get those rules written up.


Kristopher Wilson


I completely agree. I can't believe PHP has survived this long without something concrete in place. The whole current process seems like a mix of secret societies and the wild west - but not the cool Clint Eastwood kind, but the I-just-stepped-in-horse-shit-and-caught-small-pox kind.

Greg Militello


Oddly I eluded to this yesterday in your post. I have to say this is a more constructive approach than calling out people for bad behavior. This is a community issue, which should be solved by social engineering that helps weed out non-constructive "anti-feedback".

There are people who do this as their job; Riot games for instance has a team of people that do nothing but attempt to come up with way to improve their community moral and game experience. How? Well they reinforce the positives. You did well? Then you get a cookie. You done bad? No cookie for you sir. (Note; they are trying to steer clear of punishment [though some does exist], and focus on incentives).

You're right though. The time has come for PHP to take itself seriously (as seriously as it's market position suggests that it should be). I've been a PHP dev for roughly 13 years now, but recently the pastures have been looking greener elsewhere. There is no reason the language can't be more than it is.



Greg: The first step in anything is highlighting the problem. Only once the problem is understood can anyone start to consider the solution.

I feel like the community has had a week or two of problems, so anyone who was unsure, on the fence or not been paying attention should now understand the problems.

Next is the solution stage, and that has to be a positive process or it will never work.

As for the grass is greener, it's only greener on the "other side" if you're on only one side. Use a mixture of languages for their key strengths and weaknesses and you'll be fine. Make some background jobs in Go or Python or Scala. Whatever. SoA is fun. All or nothing doesn't make any sense.

Greg Militello



I agree with you here.

As for why I stay in PHP... ultimately it boils down to a solid community OUTSIDE of the core. Amazing doc (seriously, compare it to practically any other language, and you should see what I mean). Great code (See the bulk of stuff on composer, Symfony, Zend FW, etc).

As for the grass being greener argument, meh. Your right that was bad to include in my previous post. :P A non-argument from me. Feel free to disregard it.

Joe Watkins


I said an RFC without a patch is just noise, because it actually is. You do not actually disagree, you said yourself an idea without an implementation is just words ... no difference ...

I did not say if you don't know C then fuck you, I was pretty explicit in my explanation of what I meant ...

There is of course no problem with ideas coming from anywhere, I'll happily write for someone who cannot, me and many others ... I see no evidence of the attitudes you say exist, I see statements taken out of contexts and stuff found between lines that was never actually said, or likely thought ...

I agree that the RFC process is a bit broken, I don't have a solution to that, but I didn't really say the things you're making out I said ... additionally, a few guys converging on the same opinion in a thread on reddit does not give you enough to say that these are the thoughts of the whole development community at large ...



Joe: "You do not actually disagree, you said yourself an idea without an implementation is just words ... no difference ..." There is a huge difference in the meaning here. An RFC is just noise suggests its worthless, but my workflow says that an RFC without an implementation is one of the first steps in getting something done. That is completely different.

"I did not say if you don't know C then fuck you"

I definitely didn't say that you did. Firstly no names were mentioned, the fact that I used the quote earlier about "just noise" was just something you said on Reddit which seemed a good way to put it. The fact of the matter is this "implementation or STFU" approach is a barrier to entry which is not helpful, and it happens a lot.

"I agree that the RFC process is a bit broken..."

It absolutely is, I'm glad you agree. That is my point.

"I don't have a solution to that"

I'm happy to work on a new workflow. That was also the point. :)

"I didn't really say the things you're making out I said"

I never said you said a damn thing. Your name is not in this article,

"a few guys converging on the same opinion in a thread on reddit does not give you enough to say that these are the thoughts of the whole development community at large ..."

If you think all I have to go on is a few opinions on Reddit then you're way off. There are a few internals folk that are not happy with the process, so making a new one seems like a good idea.

Joe Watkins


I never said or meant C or STFU, what I said was work in small teams, just as you have said, by the time an RFC gets to internals it should be accompanied by a patch ... when you post to internals with just an idea you are starting an infinite amount of conversations, it's just not productive to do that ...

You have only to search the term "an rfc without a patch is just noise" and my name is right there ...

I don't think we actually disagree, I just didn't like my words being used to make a point I disagree with, I don't think it's such a bad thing for an RFC to have a patch and nor do you, but it seems like you are making out there is an attitude within the development community that anyone who doesn't know C doesn't have good ideas that are worth listening to, and it's just not the case, not at all ...



Joe: Yeah I think we agree on a lot of this and you're right I was misunderstanding you before.

"by the time an RFC gets to internals it should be accompanied by a patch"


"when you post to internals with just an idea you are starting an infinite amount of conversations"

As long as you can post to try to get people interested in helping you out, otherwise making these small teams is hard.

"I just didn't like my words being used to make a point I disagree with"

That's fair, it just seemed like a good way to put it. That was talking about named parameters where I was offering to update the old RFC as it was totally misrepresenting peoples current opinions. That wasn't me saying RFC's without patches are awesome, you were just saying it wouldn't help anything and I was saying it would. Either way its not the exact same conversation as circumstances there were a little different.

"it seems like you are making out there is an attitude within the development community that anyone who doesn't know C doesn't have good ideas that are worth listening to, and it's just not the case, not at all ..."

That is exactly how it is though, Every few days I see some shit like this:

Everyone has to be some big dick-swinging cowboy badass if they want to get anything done. Well, we should be proposing teams and a workflow to get there. Even if every team needs a dick-swinging cowboy to progress then thats an improvement over this elitism I see regularly at the moment.

Seeing as we MOSTLY agree, or are at least close to agreeing, and especially as you said the process could be better, would you read the FIG workflow and see if something like that could work? I've had to take care of some FIG stuff this weekend and cycled 100 miles yesterday so I've not been working on the process YET, but I'd like to bounce a few things off you when I've got something drafted up.

Joe Watkins


Good, so we (at least) agree (on); an RFC should be accompanied by a patch ... which is all I meant by an RFC without a patch is just noise ... specifically, it just creates noise, an infinite amount of noise ...

I'll come back to making teams in a minute ...

I don't know what the author of that post meant when he said "earn authority", my answer to that would be a good idea has authority of it's own ... it's a non-sense thing to say that you must earn authority ...

Now about making teams ... if you go to IRC (specifically #php.pecl on efnet) and you ask a question, you might need to wait a few hours for a response, you might need to try twice, you might receive a lecture about what is technically correct (which you should listen to every word of if you are serious about persuading minds, and bringing to completion your idea in an acceptable way), all of that being said, you will get your answer if it is out there ... the developers who hang about on IRC are nothing but helpful, they may not always be "nice", they may not always say what you want to hear, but by their very presence they are being helpful, the amount of real knowledge there concerning Zend (invaluable knowledge to RFC designers) is vast ... this seems to me an altogether more productive environment in which to discuss ideas, find developers interested in your ideas and bring about RFC's that you have heard every serious argument for and against before it's even drafted ...

IRC might be an outmoded form of communication, but it's in place, it works. So I won't be hearing the argument that IRC is old and so shouldn't be used;; HTML is old, HTTP is old, PHP is old, the earth is old; non-sequitur ...

Internals is a place that gives a very loud voice to whoever decides to talk, there is no way that internals can actually provide you with a clear picture of, well anything at all really ... I would like to hear ways of improving it, but I'm not sure anyone can really change the face of internals ... or rather I'm not really sure that you can get a consensus that says "you may change the face of internals", if nothing else because the process by which you have to seek that consensus is broken ... pretty sure though, if someone made a kick-ass interface that solves the over-arching problem of presenting a realistic view of the opinion of the community regarding any one subject (just like reddit/digg/insert any modern community driven site here), it would be adopted ... eventually ...

You know where I am, when the times comes for bouncing ...

Mike Perch





something new about the php tutoring was learnt over here and good in reading about this. Some valuable time spent here and interested in reading such like these blogs more to get an idea about php

thanks and regards

Posting comments after three months has been disabled.