Communication in Open Source

scott.wilson@it.ox.ac.uk@scottbw

What I’ll be covering in this session

1. Introduction

2. Communication channels

3. Tone, appropriateness and sensitivity

4. Communication acts

5. Communication policies and interventions

1. Why is communication so critical in OSS?

Consider this: the only thing anyone knows about you on the Internet comes from what you write, or what others write about you. - Karl Fogel

An Open Source project consists almost entirely of a set of speech acts conducted using the medium of written communication.

Written communication must therefore be a core competence for anyone involved in a project.

emailsforum postsbug reports chat bubbles blog posts screencasts documentation code commentscommit messages

Communication

• Theory in communications, particularly in business, tends to focus on transmission, encoding and feedback.

• Another way of understanding communication is to look at it as how we construct shared meaning (constructivism)

• When discussing communication we consider both the medium (channel) and the message (content)

2. Understanding communication channels

Communication takes place using communication channels

Channels have purposes, affordances, and norms

Purpose

Mark Anderson: The Leadership Book

• Communication channels can be primarily intended to be used for a particular purpose or purposes

• Purpose can be communicated explicitly (e.g. communication policies) or implicitly (e.g. follow the tone and topic of prior conversations)

Inbound, Outbound

• Some communications channels are primarily outbound, such as press releases and videos

• Some channels are primarily inbound, such as feedback surveys

• Some are both, but primarily either inbound or outbound

• Some are completely two-way, e.g. mailing lists

Private or public?

• Open Source community channels tend to be public rather than private. – There are often some private channels, for example

for handling security vulnerabilities.

• A common source of conflict in communities is where it is unclear if a channel is public or private– Make sure policies are clearly understood

Affordances

Channels differ in affordance - that is, what they support and encourage in their users

Differences in affordance occur in areas such as time, richness, depth vs. brevity, and conveying emotion

Norms and Conventions

• Channels often have norms. You often don’t notice it until someone breaks them – The multi-tweet– The tl;dr email essay

• Norms can be established by convention or be encoded into policies and rules

• Channels can also have more specific conventions adopted by the community

The Conventions of Email

Reply styles– Top Post– Bottom Post– Inline Reply/Interleaving

To trim or not to trim?AttributionReferencing and linking– direct links– numbered reference list

Some of the common conventions for email in open source projects originated in Usenet and other channels that new users will never have experienced

Personal Preferences

To what extent is choice of channel subject to personal preference?Some users prefer forums to mailing lists, and vice versa– There seem to be some demographic

differences (by age and gender) and role differences (developers vs. users)

Channel Fragmentation

• fragmentation issues - across channels, within channels (e..g. subfora)

The Meta Channel

• The way in which a project communicates - both with itself and the wider world - is critical to its function.

• Sometimes its necessary to spend effort discussing and improving communications, although a risk is that this "meta" communication can be a distraction.

• In some cases there is a place for this kind of discussion, in others it interrupts the flow

Gardeners and Gatekeepers

• Gatekeepers are responsible for keeping unwanted communications out of the channel, e.g. managing subscriptions

• Gardeners are responsible for keeping the channel content tidy, e.g. removing spam

Pulse

How do you know how a channel is being used?

- Google analytics- Built-in monitoring tools- Google Webmaster Tools- Social metrics

ACTIVITY: Mapping Channels

3. Tone, appropriateness and sensitivity

We often contradict an opinion for no other reason than that we do not like the tone in which it is expressed.

A simple rule

Don’t click “send” or “publish” if you have any doubts about how the content will be perceived.Save a draft, or leave it on screen and walk away and do something else for a while.Very few online communications have to be done immediately, and most will benefit from a few extra minutes reflection.Once you post something, its pretty likely to be impossible to retract

Terseness

Terseness is a natural habit when communicating often.Not to be confused with brevity, which is usually a desirable qualityTerse content can be interpreted as coldness or lack of emotionMost regular members of a community are probably used to terseness, but be prepared to be more verbose with newcomers

Adding context for newcomers

The elements that you tend to leave out of communications are contextual information that is shared in your community. However, for newcomers its useful to put it back in.

Salutations “hi new-user-x”Introductions “I manage this component”Background “This is used for xyz” Sign off “good luck and I hope this explanation helps”Links and references

if you’re going for a RTFM-style reply, you should at least have the grace to provide the link

Rudeness

• Recognising rudeness:– Ad hominem comments and insults– Deliberate ignorance “I didn’t read your post, but I think…”– Intentionally condescending comments– But criticism isn’t inherently rude, and directness should be

valued. However, consider using a “criticism sandwich”

• Dealing with rudeness:– Interventions need to be timely, and douse the flames rather

than feed them. Be boring and repetitive if necessary.– Don’t demand apologies

An example

“First, let's please cut down on the (potentially) ad hominem comments; for example, calling J's design for the security layer "naive and ignorant of the basic principles of computer security." That may be true or it may not, but in either case it's no way to have the discussion. J made his proposal in good faith. If it has deficiencies, point them out, and we'll fix them or get a new design. I'm sure M meant no personal insult to J, but the phrasing was unfortunate, and we try to keep things constructive around here.

Now, on to the proposal. I think M was right in saying that…”

- From Fogel, K. Producing Open Source Software

Creating a “criticism sandwich”

Start with the positive:“Thanks for the patch, this is addressing a really useful use case”

Go onto the negative:“However, I noticed the code in the patch doesn’t follow the project style guidelines, particularly around comments. You need to correct this and resubmit the patch.

Finish on a positive:“Overall this is a great addition to the project, and I look forward to receiving the resubmitted patch so I can apply it to include in the next release”

Right message, wrong channel

Some of the worst examples of miscommunication in open source fall into this category– The legal debate on the developer list. – The build process debate on the board list.– The personal-qualities-of-committer-x on the public

list…– The policy debate via twitter– The “scottmail” – Any more?

Humour and sarcasm

Humor can be very culturally-specific and is a common source of miscommunication.

Sarcasm is also quite difficult to convey online and is easily misinterpreted.

Sticking an emoticon on the end of a sentence really helps :)

Studies have shown people routinely overestimate their ability to convey sarcasm (Kruger et al 2005)

Internetese

ACTIVITY acronym time

Diversity and Difference

“Surface-Level” - Race, Gender, Age

“Deep-Level” - Skills and personalitiesGraen, George B. - Dealing with Diversity

Referring to groups

“As a general rule, it is good to remember that you should only refer to a person by category when it is relevant or necessary to the discussion at hand. That is, you should ordinarily view people as individuals and not mention their racial, ethnic, or other status, unless it is important to your larger purpose in communicating.”

American Heritage Book of English Usage

Avoiding Casual Sexism

• Avoid generic gender-specific pronouns in English– Use roles and nouns instead when describing hypothetical

scenarios, e.g. “the user”– Switch from first to second or third-person– Switch from singular pronoun to article “his issue -> an issue”

(or the “singular they”)– See also Klein (1993)

• Avoid stereotyping– There is usually no need to explain or amplify a role based on

gender, e.g. “ a female developer”• Be especially careful in policy documents and

communications that set the norms and conventions

ACTIVITY Debug the sentences

Professions and Skills

The advice on groups applies equally well to professions as to ethnicities and gendersProfessional stereotyping

– “Even a tyre-fitter can use this”– “Only a librarian would care about adding keywords”

Professional respect– “Anyone can write documentation”– “Developers have no social skills”

Playing up to a role–“Speaking as an experienced developer, your code sucks”–“I’m a manager and I wouldn’t put up with…”

Accessibility and Usability

Accessibility and usability often go together; if you make the effort to make your content and communications more accessible, you usually help everyone.For example if you use an image to communicate, provide text that describes it - this is not only useful for users with visual impairment, it makes your content more easily discovered, summarized and reused.

4. Communication Acts in OSS

Communicating Identity and Presence

A common type of paraverbal communication is how we communicate our presence online, or our presentity

DeathDealer666Perl Hacker and Evil Wizard

Member: peoplewhohatecheese

Presentities: risks and rules

• Presentities can convey the wrong message regardless of what you actually say

• Presentities do not usually map onto real identifies

• Presentities also have their own norms and unwritten rules, and can also be subject to policy– For example, is it a community of individuals or

representatives of organisations?

Whats in a name?

Speech Acts

Inquiring

Paraphrasing

Acknowledging

Advocating

Speech acts are a way of categorising the content of conversations

SummationDecisionUnblockingReframingIndividual Follow Up

Unproductive Threads?

• Arguments that have been made already start being repeated, as though the poster thinks no one heard them the first time.

• Increasing levels of hyperbole and involvement as the stakes get smaller and smaller.

• A majority of comments coming from people who do little or nothing, while the people who tend to get things done are silent.

• Many ideas discussed without clear proposals ever being made.

Karl Fogel, Producing OSS

Bikeshedding

a.k.a Parkinson's law of triviality

Discussion Points

Which are the common speech acts in your project community?

Which speech acts do you think are missing or you’d like to see more of?

5. Communication Policies

Establishing the ground rules

Welcoming newcomers

Handling common problems

Establishing ground rules

http://typo3.org/community/code-of-conduct/

(based on the ubuntu code of conduct)

Welcoming newcomers

• Newcomers to a community can be easily put off by the tone of responses. – This is usually unintentional on the part of existing

community members (its hard not to be abrupt when closing yet another duplicate bug report)

• Communities have come up with a number of strategies for dealing with this issue

Bugzilla

“New to Bugzilla”

“First patch”

Mediawiki

Greeters

• A "greeter" is someone who takes a role of responding to newcomers to a community

• A greeter can also "reset" the tone of a conversation early on if the inbound message could come across as abrupt or aggressive.

• In most projects this is informally something done by one of the community members (and doesn't even have a particular name or role associated with it). In some cases the community manager also performs the "greeter" function. Some projects however have created a specific role and even an identified greeter team.

Resources• David Eaves, Wiki's and Open Source: Collaborative

or Cooperative? http://eaves.ca/2007/02/05/wikis-and-open-source-collaborative-or-cooperative/

• Fogel, K, Producing Open Source Software• Bacon, J. The Art of Community • Kruger, J., Epley, N., Parker, J., & Ng, Z. (2005). Egocentrism

over email: Can we communicate as well as we think? Journal of Personality and Social Psychology, 89, 925-936.

• Graen, G. B. (2003) Dealing with Diversity IAP• Klein, J. (1993) Avoiding Sexist Language,

http://www.hamilton.edu/writing/writing-resources/avoiding-sexist-language