TYPO3 Communications Workshop: Communications
Download as PPT, PDF1 like684 views
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.
TYPO3 Communications Workshop: Communications
- 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
- 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
- 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
Editor's Notes
- #29: David Cameron: “Hi rebekah, keep your head up, LOL DC” Rebekah Brooks: “Thanks Dave, it doesn’t mean Lots of Love, it means Laugh Out Loud”