March 24th, 2013

purple hair

Let's talk about social contracts.

Skip this post if you're sick of hearing about Donglegate.

We'll start with a little history. You might have noticed, in the KYM synopsis, a reference to the PyCon Code of Conduct, a document largely derived from boilerplate language originally advanced, systematically, by the Ada Initiative in August 2012. The PyCon code asserts that "all delegates/attendees, speakers, exhibitors, organizers and volunteers at any PyCon event are required to conform to" it, and identifies organisers as the enforcing authority. I'm pretty comfortable with calling that a social contract, voluntarily assented to by the actions of registering for the conference and accepting a badge. Furthermore, during the conference, wearing one's badge serves as an ongoing signifier of one's participation in this social contract. (More on that in a little bit.)

How about terminating the contract? Ejection without refund is a penalty explicitly stated in the PyCon code, so there's one condition under which the contract may be terminated; to the extent that badges serve as a form of access control1, requiring attendees ejected under the code to surrender their badges signifies that their participation in the social contract has been terminated. Presumably, then, an attendee/speaker/exhibitor/volunteer/organiser could also, having voluntarily assented to the contract by registering, also voluntarily withdraw from the contract (symbolically, by handing their badge back to the organisers and leaving).

Keep that last part in mind; it has knock-on effects.

I've gotten into a few discussions on Twitter, which I'll just summarise here but can maybe summarize in a Storify or something if sufficiently incentivised to do so, about the PyCon organisers' efforts to revise the language of the code in the wake of Donglegate. As this year's chair Jesse Noller comments in that thread, "Explicit is better than implicit" -- quoting from the Zen of Python, which (like so many things) probably started as a ha-ha-only-serious bit of humour but has come to be embraced as a sort of normative philosophy for building both Python the language and Python the community. As another commenter in the same thread predicted even earlier, though, "it's inevitably going to be looked on as a gagging provision" -- even though, as Jesse then points out, staff are attempting to clarify the language to better express their already existing, and unchanged by this incident, perspective on the aggregate damage that the "name and shame first" approach readily leads to.

Presumably, opponents of policy change are disappointed to see that PyCon does not take their side in encouraging the name-and-shame-first strategy. But I think it is disingenuous of them to portray the change as a gagging provision. As of the current revision, the policy makes the following changes related to place, time, and manner of speech about violations of the code:

Unlike much of the other language in the code ("Be kind to others. Do not insult or put down other attendees. Behave professionally. Remember that harassment and sexist, racist, or exclusionary jokes are not appropriate for PyCon."), these items are phrased as requests, not requirements. Maybe putting it in RFC-speak will make it a little clearer:

  • You MUST be kind to others.
  • You MUST NOT insult or put down other attendees.
  • PyCon staff SHOULD be your first resource when reporting a PyCon-related incident.
  • You SHOULD NOT disclose public information about the incident until the staff have had sufficient time in which to address the situation.

And, indeed, when we look at the IETF's definitions of these four terms:
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.

2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
we see that these terms in fact capture Jesse's concerns. There are very valid reasons to take an issue public, but doing so carries with it certain risks, regardless of the validity of one's actions. I think it's reasonable on the part of PyCon to express an organisational opinion on this matter, and given that their opinion as expressed is 1) only a recommendation, and 2) even if followed, delays public disclosure by a matter of hours, I don't find the recommendation particularly chilling with respect to speech in general. I would attend a conference with such a policy; I already live in a country2 that asserts exclusive right to all executive and judicial power, so spending some time in an environment where the agreed-upon authority has put some thought into which conditions of its social contract are optional and which ones aren't is really kind of refreshing.

And now we get back to the part from earlier about terminating contracts: if I go to a conference with a code of conduct, even one with a straight-up gag rule (which, again, I don't think PyCon's is), some code of conduct violation happens, and I'm unhappy with both the resolution and my ability to talk about it under the terms of the social contract, I can withdraw from the social contract. See, organisations can breach terms of contract too. Organisations that breach their contractual obligations sufficiently, or are negligent, can be held liable for this in civil court. Liability and harm are of course closely interrelated; a con staff that, for instance, (warning: extreme example) concealed evidence of a rape and discouraged the victim from contacting police has obviously gone well beyond breach of contract into becoming accomplices to felony conduct. (In a case that extreme, the last thing the victim should have to think about is any perceived sense of obligation to honour a social contract that the organisation long since put into a crosscut shredder and pissed on.)

Had Adria Richards gone to the PyCon staff and been dissatisfied with the outcome, it's questionable whether she would have been able to, say, recoup the cost of admission in a civil breach of contract suit. I'm not sure whether the PyCon code is, even now, worded well enough to hold much water in a civil court; I don't get the impression the Ada Initiative consulted a lawyer when they developed it, though if someone has better information on that, I'll correct that in-place.

But my point is, organisations also have incentives, long established in the civil court system, to hold up their ends of the bargains they've made. A lot of the people I've talked with have raised the question, "Why should we necessarily trust that staff will do a good job of resolving the issue?" And this is the part where I start tearing my hair out -- because the loudest voices shouting this demand are the same ones who demanded that codes of conduct be instituted in the first place. Why even bother asking an organisation to modify its policies on your behalf if you don't trust the organisation enough to use the reporting channels and protocols it established because you asked for them? Isn't that a signaling of trust, of good faith, on the part of the conference organisers that these channels will be used?

These are questions I don't get a lot of answers to on Twitter.

1I didn't have a ticket to PyCon, but had no problem wandering around the public areas, the expo, and the sprints (which are all open to the public). I didn't bother trying to wander into any talks, though I don't think I would have been stopped. Other conferences, e.g. Black Hat, have a strong public/private space distinction (anyone can walk into the Expo, but you will get kicked out if you try to get into talks without a badge); others are tighter still (it's easy to get a free badge to get into the RSA Expo, but you're not even getting into that without one). Tl;dr (too late): "are badges access control" is a question with a different answer for each conference, and "access control to what?" is an important question for each conference to ask when deciding their overall answer. Proceed with context. Infinity welcomes careful drivers.

2Which country? All of them!