(1 comments, 54 posts)
This user hasn't shared any profile information
Posts by padraic
In a previous post, I summarised and made some observations about the draft RFC for a PHP Code of Conduct. Just to clarify, this would apply to the PHP Project (i.e. Internals). It’s obviously not being imposed on the bazillion PHP programmers that make up the wider community. However, I found myself then troubled by some of the opposing views. So I’m back again. I’ve burnished the pulpit, double checked the mic, and adjusted the soapbox height.
Let loose the meandering long winded throughts!
What is a Code of Conduct?
The most elemental form of opposition to the RFC was outright rejection. No Code of Conduct, please, said a minority of respondents. This struck me as irrational. It’s important to understand that while the RFC’s Code of Conduct is a text document, it’s purpose can be construed as expressing a pre-existing code of conduct. The one each of us already carries around in their head as part of a community.
TL;DR: We already have a code of conduct. Well, codes. Plural.
This is easily proven by serving up a little thought experiment. A PHP Internals programmer and I have been arguing back and forth on a topic. At some point, they make a derogatory comment about my potato eating skills. I complain to PHP Internals about this conduct. What is the reaction of the PHP Project? Remember now, there is no Code of Conduct. Right?
There is a Code of Conduct?
If there was no code of conduct, then nothing would happen. I would henceforth be referred to on an ongoing basis as Mr Potato-Eater. If there was a code of conduct, however, then something will happen.
You can guess the outcome. By some sleight of hand, a code of conduct which doesn’t exist will miraculously manifest itself and be exercised. The offender will be booted off the mailing list for a time out.
Fine, this does raise the other negative possibility, that Mr. Potato-Eater becomes an unchallenged mode of addressing me. I curse the PHP project, express my disgust at their inaction, and exit stage left. I think most of us can agree that that would never happen, were the original scenario to materialise. Then again, who’s publicly going to state otherwise?
The fact is that the PHP project, and the wider community, have a code, a set of traditions, a culture, call it what you will. If you take the time to describe it, there will emerge something that suspiciously looks like a Code of Conduct. It will be incomplete, a unique personal view, and untested. But there it is.
So, to anyone hellbent on there being no code of conduct… Too late. That battle was lost long ago, the war that remains is arguing its content.
A Code of Conduct Kills Free Speech
Any notion of unrestricted free speech applying to the PHP Project is entirely false. While the subject of my experiment could have run around the streets complaining about the scourge of potato-eating Irish folk (I assume in full 19th century dress), as he would be entitled to do in some nations, does anyone seriously think he could do so on the mailing list? At a PHP conference? On Twitter to a fellow project member? In private correspondence to a fellow programmer? On IRC, at 3am, with a group of friends to a fellow programmer? While skiing the slopes of Mount Olympus on Mars using the NASA network to IM a fellow programmer who posts funny GIF summaries on Facebook?
And suffer no consequences at all?
Membership of any community immediately exercises a chilling effect on certain speech, within the sphere of that community, or when engaged in community affairs. It’s a natural outcome of being a cooperative member of the community. You conform, in some way, to that community’s expectations to achieve its goals.
The PHP Project is no different. It’s an international community with members of widely diverging views and cultures. Members and participants naturally self-censor to an appropriate level in order to achieve the community goals, i.e. writing good code. They can all likely have a good argument outside of PHP on any topic under the Sun, and often do. They simply work on keeping the two distinctly separate and unrelated.
A Code of Conduct, in written form, doesn’t magically change the above situation. It has a limited scope and area of effect, or should do, and any attempt to go beyond its remit should be explicitly denied. At the same time, you can’t have a Code of Conduct which tries to remain blissfully ignorant of public and private activity by restricting itself to community conduct on a narrow subset of media. The real world does not conform to wishful thinking.
What Is This Unspoken Code Of Conduct?
I don’t know. Do you? If you ask two people to write down a description, will any two of their descriptions agree? Of course, if you write it down, then I can quote it. I can refer to it. I can use it.
Or I can keep on guessing. And some folk can keep on pretending that it doesn’t exist.
This is the essential outcome of a written Code of Conduct: you eliminate uncertainty. It has been written down, agreed by the community, and it reduces guesswork to a minimum (a number less than infinity). It’s an advertisement that we all sat down, had a discussion, and synchronised our pre-existing unspoken codes. Should anything now or in the future require actually following the process that a Code of Conduct lays out, the PHP project can avoid looking like an insensitive headless chicken, paralysed by indecision, as it improvises and muddles its way through. Instead it can hopefully deal with the situation quickly and efficiently.
Iterative improvement FTW.
Abusing the Code of Conduct
Another point of opposition to the Code of Conduct, as drafted in the RFC, was that it would allow for the abuse of that Code.
Since we already have a few hundred unwritten codes of conduct buried at the back of our collective mind, what makes THOSE codes immune to abuse as things already stand? Does the absence of a written Code of Conduct eliminate the opportunity for abuse?
Since there’s no written Code of Conduct, there is no documented complaints process. There is no evidence requirement. There is no appeals process. There are no designated complaints handlers. There is no requirement for confidentiality. There is no definition or suggestion of what is, or is not, subject to being complained about. There are no time-frames for resolution of complaints. There are no immediate reliefs on offer. There is the possibility of unilateral action by an individual of merit. There is the possibility of no action by anyone. There is the prospect of ignorance as nothing is reported, acted upon or transparently disclosed.
And folk worry about a written Code of Conduct being abused…
Any process, written or unwritten, can be targeted for abuse. It does not therefore follow that we should not have processes. It does follow that we should make processes which are resistant to abuse.
The Overextended Code of Conduct
I completely agree, on the most obviously sensible point, that there should be a divide in any Code of Conduct, with examples, as to what is and isn’t considered offensive. PHP Internals is sometimes described as “toxic” with impassioned, chaotic and sometimes cutting emails. That idea is a well established part of PHP’s reputation.
That doesn’t mean that toxicity should be mentioned in a Code of Conduct as something to be punished.
The dividing line is essential to avoid confusion over when the Code of Conduct actually applies, and to the extent it applies. Debates over controversial topics will often become heated, tempers may fray, and the occasional swear word, debate tactic or cutting wit may offend someone. That’s often how debates work, period. If you can’t stand the heat, then don’t stand in the fire. It may be totally counter-productive at times, and divisive as all hell, but that doesn’t automatically mean rolling out punitive intervention.
At the same time, we can’t deny the inevitable. No matter how many examples we provide, or explicit text we add, there may be scenarios that are open to interpretation. At some point, trust needs to laid in the people selected to make final determinations.
This applies whether there is a Code of Conduct, or not. The community contains people. Those people must make decisions with a Code or in the absence of a Code.
The Improvised Code of Conduct
The worst possible outcome for the PHP Project is the headless chicken scenario. A complaint is lodged, probably publicly. The Project is then forced to improvise a Code of Conduct on the fly. No RFCs. No debates on the mailing list for the next month. Just make it up, right then and there, and act on it.
The first improvised Code of Conduct will be Do Nothing. Followed by Do Something. It would then be followed by something greater than two words evolving organically. Dice rolls may be involved. The intestines of goats may be consulted. The crystal ball market will boom.
The problem with improvisation is that it risks inconsistencies, ill-considered outcomes and knee jerk reactions. If, in the face of a complaint, the response of the PHP Project is to do nothing, very little, maybe something, then how do you expect genuine victims to respond? Is that the sort of community that anyone aspires to?
If the outcome is to do something, then the project faces the same problem being debated right now. Is this complaint valid? What processes should be applied? What outcomes should result?
Why didn’t we just resolve this in January of 2016?
The Code of Conduct As A Solution In Search Of A Problem
Once upon a time, there was a village. It was a nice village. One day, on a bright sunny morning, one of the villagers was murdered. Quite shocking. Even more shocking, since there had never been a murder in this sleepy village before, there was no law against it. Undeterred by this oversight, the villagers strung the murderer up on a nice tree by the pond. Followed several weeks later by the real murderer. Oops.
The point is that not having a robust solution for situations that arise in the real world, only makes perfect sense if you can predict the future and it’s all rosy. I assume none of you can. Otherwise, plan accordingly for stuff that really happens every day in that real world, even if you feel totally untouched by them, and try to make decent solutions that don’t explode in your face should you ever find yourself needing to apply them.
Also, pay more attention to the real world.
Debate the text of the Code of Conduct, or learn to read tea leaves ;).
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: https://www.drupal.org/dcoc. WordPress is looking at one though it’s anyone’s guess as to progress: https://meta.trac.wordpress.org/ticket/957. You can find lots of other examples whether related to PHP or not.
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:
- What conduct is considered objectionable by the COC?
- Who is covered by the COC and in what circumstances?
- What level of evidence is required?
- What if an accuser seeks to abuse the Code dishonestly?
- 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 php.net addresses, but I don’t see why it needs to be that narrow. If someone without a php.net 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.