How Not To Have A Conversation

By and large, it’s one of those teapot squabbles that the intersection of Twitter and Open Source can easily make more heated than enlightening. My interest here isn’t to pick a side and point fingers thither and there, if only because it’s pretty hard to point fingers and type at the same time. Rather, I wonder if the heat could not be harnessed to cook up something useful.

A brief summary of events. Yesterday, I noticed through a discussion between others that the eslint page on npmjs.org had a pretty minor problem: one of the images was loaded off http instead of https, which caused mixed content issues. So I clicked through to GitHub, clicked on the README, clicked “edit”, added the one little missing character, filled out an explanation of the problem, and hit “submit”. The total processing time was almost certainly less than a minute. In the PR, the maintainers asked twice that I reformat the commit, which I declined twice; and the PR was closed (@brianloveswords later sweetly put the matter to rest).

As I said, I do not want to get into the rights or wrongs involved.

The first thing I would like to note is that in the relatively large ensuing Twitter conversations, no one was ever aggressive or openly rude (if so, I wasn’t copied on it). Compared to pretty much any other open source community I have been a part of, and certainly compared to the open standards community, that is a marvelous achievement.

I know that some people considered my characterisation of the maintainers’ behaviour as “ridiculous” to be rude. If that is how you feel, I apologise. I went for “ridiculous” as a kinder, gentler word for “absurd”, which I would already not consider to be rude.

I don’t care to nitpick that point: the fact is that while improvements are always possible the JavaScript community can be frightfully nice, that it makes me proud to have “JavaScript — FOR SCIENCE!” as my day job, and if you have found me rude in this instance, it was unintentional and I reiterate my apology.

The second point that I find interesting, and about which we might elect to do something, is that people are very divided on what the correct behaviour ought to have been. This is somewhat problematic because it indicates that the situation will occur again, elsewhere, and it is often from the tiniest quibbles that the harshest feelings arise.

I will try to characterise both views fairly. Imagine this situation: I am walking down the street while speaking on the phone. I notice that you drop a pen on the sidewalk just as you enter a café. I pick the pen up, pop my head in and, without hanging up, hand it over to you. However, the café has a strict “no phones” policy. So instead of taking the pen, you ask me to step back out, hang up, and come back in.

That is where two schools of thought part ways. Mine would be to put the pen back on the ground, make some form of “meh” gesture, and walk on. I tend to consider irredentist adherence to rules to be detrimental to all involved. The other school of thought is that it is hard to run a cool café, that it’s up to whoever owns it to decide what the rules are and how strictly they get applied, and that frankly putting someone else’s pen down on the ground right in front of them is just a wee bit of a dick move.

You will note that no one is saying that rules promoting phone discretion in cafés are bad. We all agree that there is a special Céline Dion karaoke reserved for people who bellow into their phones in small enclosed spaces.

You might also note that the two approaches are not actually incompatible. Neither is completely wrong; and both are slightly unpleasant. I am not convinced that one can decide which is the better behaviour through pure reason; rather, we need convention.

Which leads me to an open question: should we, as a community, take the time to write down a common contribution code that projects could reference? It would include codes of conduct, but also go beyond into the expected mechanics of contribution-making. It would not keep projects from having their own style or setup of course, but would document common expectations. One of the (minor) topics it could cover would be whose responsibility it is to fix up micro-contributions: contributor or maintainer. This (and larger, more contentious problems) can be discussed in a coolheaded manner. Should such a code arbiter in favour of the strict application of rules, I might decide to shy away from smaller fixes to projects I am not already a part of, but I would happily abide.

One possible outcome might be a typical set of contribution-management tools that allow maintainers to be flexible rather than locking them into being rigid (as may have been the case with this incident). One interesting point of comparison here could be the W3C universe in which contribution rules can be staggeringly strict and impenetrable (so as to ensure that contributions keep the Web royalty-free). In order to keep participants sane (or at least, to delay the descent into insanity that the standards world will inevitably inflict upon them), requisite information can be provided simply through comments on a pull request and maintainers can accept theoretically invalid contributions if they assess that they do not affect normative parts. Creating flexible tools is a fair bit more work than creating strict ones though (as the ESLint people must no doubt know), so a shared body of expectations might help to produce such an ecosystem.

I am not entirely sure that it is a good idea (as you may have noted I do not necessarily hold rules in that high a regard…); I am just putting it out there for discussion. I thought it might already exist but could not find it.