PHP General

A Code of Conduct for the PHP Project?


This is not the Code you are looking for…

As you’ve likely hear, Anthony Ferrara has written a draft RFC for a Code of Conduct which would apply to the PHP project. The thread on PHP Internals is currently up to 300 emails and counting.


The draft is based on the Contributor Covenant which you can find here with translations.

Do nothing… something… anything?

Of course, it’s a curiosity to contemplate if at any time such a COC could, should or would have been applied in the past. It can even be tempting to conclude that no such events have ever occurred.  So long as you remain very quiet, ask nobody, and ignore the denizens of the public PHP world, this query will lead to no results whatsoever. The problem is that this approach is irrational. A lack of evidence for something, does not disprove its existence, if there is also a lack of evidence for alternatives. Essentially then, we can conclude nothing. The simpler bet is to simply take a look outside of PHP.

It is, of course, self-evident from other sources that any large community can, and most probably has been, subject to what most of us would agree is objectionable behaviour. This is a basic fact of everyday life and leads to the question of what should the PHP community do to express disapproval, discourage such behaviour, resolve such behaviour, and, if necessary, punish it. Since it’s actually been a fact of life since forever, most nations and corporate entities have laws/codes/regulations designed to counter such behaviour, and punish them in many cases.

What makes the PHP community any different to the real world? Does it occupy its own bubble universe free of any vestige of human nature? Is it truly believable that not one example of objectionable behaviour has ever occurred in the long history of the PHP project?

For the sake of argument, let’s assume that Developer X has just called Developer Y a dim-witted moron. Repeatedly. Between individuals, this matters not a whit and there’s no law against it (at least where I am). Within an organisation with shared goals, like a company, this would be interpreted as harmful to the attainment of those shared goals. There’s likely a regulation or two where this can be reported up the chain with consequences for the subject of the complaint ranging from a simple apology to being fired.

If we look at the PHP project, there is precisely diddly squat that the victim of any such abuse can do other than block the offender on social media, publicly denounce then, and if they persist, quit the project entirely and get on with their lives once they recover from the shock, disgust and mental harm inflicted by another. How would this serve the PHP project’s shared goals?

This purely hypothetical situation damaged those goals. It allowed a situation to exist that discouraged participation and vindicated the ability of an individual to inflict harm on another member of the community without consequence to themselves. This is a totally unacceptable outcome. It’s unacceptable from the view of the goals of an organisation and, more critically, it’s unacceptable on a basic human decency level.

“When bad people combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle.”

You’d be most familiar with the common rephrasing of the above to “evil thrives on the inactivity of good people”. Doing nothing serves only those demonstrating behaviours that a Code of Conduct would seek to discourage. Worse, such behaviours are likely to evade public attention since there’s no mechanism to report, enumerate, track or disclose them. The resulting position of ignorance is, to a degree, a factor in the current debate. Inaction does not serve the community, nor does it serve the victims or incidental bystanders to such behaviour, but inaction itself thrives on ignorance. You can see the resulting pattern: ignorance leads to inaction; inaction maintains the status quo.

A Code of Conduct is not just a great idea, it’s the only possible idea short of doing nothing at all. It’s an expression of a community’s willingness not to tolerate unacceptable behaviour in its midst. Unless, of course, I’ve mischaracterised its willingness…

This one debate raises another question. The RFC is for the PHP Project. The same debate inevitably extends to other organisations and projects within the PHP community. For example, Drupal already has a COC: WordPress is looking at one though it’s anyone’s guess as to progress: You can find lots of other examples whether related to PHP or not.

Frictional Differences

Once a Code of Conduct become inevitable, there needs to be a lot of thought put into how exactly it operates. While it might be tempting to assume it would never be used, I’d put my money on the opposite. It will be used. Afterall, it’s a bit silly to create a Code under the assumption nobody will use it.

The COC as currently drafted is broadly split into two procedures following a report of unacceptable behaviour: mediation and/or removal of privileges. Mediation is essentially talking in private to resolve the issue without necessarily going public. Where mediation fails, the issue may become public knowledge due to the application of punitive outcomes. At all times, there is an assumption that the identity of the accuser will be kept private (from the public). It’s unclear if there’s any consequence to the accused should they unilaterally make the accuser’s identity public. Digging into every detail of the Code of Conduct is beyond the scope of one blog post, however do read the draft RFC for yourself.

From the debate thus far, the issues raised, assuming the COC were implemented, cover a range of concerns:

  1. What conduct is considered objectionable by the COC?
  2. Who is covered by the COC and in what circumstances?
  3. What level of evidence is required?
  4. What if an accuser seeks to abuse the Code dishonestly?
  5. Would members of the community be suitably independent, trained, etc. to make judgements?

I’m ignoring tangential concerns over whether a COC is needed, covered earlier. If you follow all of the emails, there tend be tangents of tangents… It would be far more valuable to simply stick to clarification of what the draft RFC already includes, and reducing the debate to the basic principles of a Code of Conduct that would be agreeable to the community. I briefly outline the above points below though I’m sure additional future debate will modify these over time.

Unacceptable Behaviour or Conduct

The draft Code of Conduct defines objectionable conduct as follows:

Examples of unacceptable behavior by participants include:

  • The use of sexualized language or imagery
  • Personal attacks
  • Trolling or insulting/derogatory comments
  • Public or private harassment
  • Publishing other’s private information, such as physical or electronic addresses, without explicit permission
  • Other unethical or unprofessional conduct

In essence, it’s an open ended list of examples which can therefore be reduced to one single phrase “unethical or unprofessional conduct”. The definition of that phrase, while it may seem broadly obvious to each of us, would likely help though clearly we can’t duplicate a book on the topic! The implication, of course, is that the people involved in enforcing the COC would effectively need to judge what is or isn’t unethical or unprofessional conduct.

Who’s Covered by the Code of Conduct?

Another debateable point, we could just reduce the covered population to those against whom a punitive action could be taken, i.e. anyone using the resources of the PHP project and who could be banned from their use. One could reduce it further to those with addresses, but I don’t see why it needs to be that narrow. If someone without a address were discussing a topic on the mailing list, it appears rational to assume that they are covered by the Code of Conduct by virtue of utilised a project resource they can be banned from using.

The definition of the covered population also needs to account for technical avoidance. If I am discussing a topic on the mailing list and I make unacceptable but related comments in private emails or on Twitter, the non-PHP forum used should not magically preclude me from the Code of Conduct. Those external inputs are demonstrably related to my activities on the mailing list. As would giving talks on PHP Internals related topics, for example. A similar test can be applied for any conduct – whether it be public, private, online or offline.

The objective, obviously, is to reduce avenues of allowed misconduct. As a thought experiment, imagine that a conversation has finished on a mailing list. I wait a few days, then spam a project contributor in the project with insulting emails and tweets which cleverly make no reference to PHP whatsoever. There’s no immediate link between a PHP and my tirade of abuse. Does the Code of Conduct apply in this scenario?

Level of Evidence? Abuse of the COC?

The above two concerns are interlinked since it should be next to impossible to abuse the COC if the evidentiary requirements are sufficiently defined. Practically any process can be abused by falsifying evidence or extending the intended coverage of the process. More specifically, it’s reasonable to assume that were “unacceptable behaviour” sufficiently vague, such that the phrasing was vulnerable to being interpreted more broadly than anticipated, then the potential for abuse of the system exists.

Notably, the COC counters this possibility by requiring transparency. A summary of events and the evidence of any unacceptable behaviour must be produced at the time when any punitive action is proposed. Additionally, an individual can raise an appeal to the PHP Internals group as a whole.

Suitability of the Conflict Resolution Team

There’s no inherent requirements documented that would inform the community as to who should be appointed to the resolution team. Considering that PHP Internals is largely a meritocratic organisation, it may well be a matter of volunteers with perhaps some consideration of diversification of viewpoints as a safeguard against becoming a tool that makes a mockery of the COC, whether over- or under-. In short, it’s not like there is an alternative. As noted previously, the COC calls for an appeals process which will put the brakes on any ill-considered actions by the Team.


And there I’ll leave it. Lots of debate to follow, I’m sure, and it will be interesting to see the draft take shape.

Self-Updating PHARs: Stable phar-updater packages now available


I recently released the first stable versions of my phar-updater package. So there. Announced. Can I go back to playing Witcher 3 now?

In all seriousness, phar-updater is my implementation of recommendations I made in a previous blog post around self-updating PHAR files. Those recommendations were, predictably for me, largely concerned with self-updating from a security perspective. Implementing it brought ease of use and flexible integration to the fore also. It can be surprising what a little extra work, testing and packaging can accomplish for reuse compared to throwing code into one file and calling it a day. It’s been integrated into Humbug with nary an issue.

You can find all the gory details about the package in the Github README: Don’t panic. I added a contents table.

The phar-updater package covers a number of self-explanatory features:

  1. It supports updating currently running or other local PHARs.
  2. It supports updating from any generic remote URL (using SHA tracking), or from Github Releases using tags conforming to semantic versioning.
  3. It enforces TLS verification, and supports OpenSSL PHAR signatures.
  4. It has a simple version parser, allowing flexible configurable updates based on stability, pre-release status (alpha/beta/rc) and version number.
  5. You can perform remote checks for available updates.
  6. You can add custom remote strategies as needed.

This is all pretty much everything I’ll ever need from the package. It’s small, simple, and should require minimal maintenance. And…really, I have nothing more to type. I’m all typed out unless the keys are W, A, S and D.

You can see phar-updater’s API evident in Humbug which serves as a good example of how to use it in practice within a Symfony Console command:

Go to Top