Communication is critical in open source projects as most interactions occur through written communication channels. It is important to understand the various communication channels, their purposes and norms. When communicating, one must consider tone, being appropriate and sensitive to different groups. Common communication acts in open source include inquiring, paraphrasing and acknowledging. Establishing communication policies helps set ground rules and guidelines for welcoming newcomers and handling issues.

1. Communication in Open Source
scott.wilson@it.ox.ac.uk
@scottbw

2. What I’ll be covering in this session
1.
2.
3.
4.
5.
Introduction
Communication channels
Tone, appropriateness and sensitivity
Communication acts
Communication policies and interventions

3. 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

4. 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.
emails
forum posts
bug reports
chat bubbles
blog posts
screencasts
documentation
code comments
commit messages

5. 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)

6. 2. Understanding communication
channels
Communication takes place using communication
channels
Channels have purposes, affordances, and norms

7. Purpose
• 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)
Mark Anderson: The Leadership Book

8. 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

9. 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

10. 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

11. 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

12. The Conventions of Email
Reply styles
– Top Post
– Bottom Post
– Inline Reply/Interleaving
To trim or not to trim?
Attribution
Referencing 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

13. 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)

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

15. 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

16. 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

17. Pulse
How do you know how a channel is being used?
-
Google analytics
Built-in monitoring tools
Google Webmaster Tools
Social metrics

18. ACTIVITY: Mapping Channels

19. 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.

20. 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

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

22. 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

23. 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

24. 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

25. 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”

26. 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?

27. 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)

28. Internetese

29. ACTIVITY acronym time

30. Diversity and Difference
“Surface-Level” - Race, Gender, Age
“Deep-Level” - Skills and personalities
Graen, George B. - Dealing with Diversity

31. 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

32. 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

33. ACTIVITY Debug the sentences

34. Professions and Skills
The advice on groups applies equally well to professions
as to ethnicities and genders
Professional 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…”

35. 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.

36. 4. Communication Acts in OSS

37. Communicating Identity and
Presence
A common type of paraverbal communication is
how we communicate our presence online, or our
presentity
DeathDealer666
Perl Hacker and Evil Wizard
Member: peoplewhohatecheese

38. 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?

39. Whats in a name?

40. Speech Acts
Speech acts are a way of categorising the content
of conversations
Inquiring
Paraphrasing
Acknowledging
Advocating
Summation
Decision
Unblocking
Reframing
Individual Follow Up

41. 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

42. Bikeshedding
a.k.a Parkinson's law of triviality

43. 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?

44. 5. Communication Policies
Establishing the ground rules
Welcoming newcomers
Handling common problems

45. Establishing ground rules
http://typo3.org/community/code-of-conduct/
(based on the ubuntu code of conduct)

46. 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

47. Bugzilla
“New to Bugzilla”
“First patch”

48. Mediawiki

49. 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.

50. Resources
• David Eaves, Wiki's and Open Source: Collaborative
or Cooperative? http://eaves.ca/2007/02/05/wikis-and-opensource-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/avoidingsexist-language