Download as PDF, PPTX
Uploaded byosswatch
Communication in Open Source
This document discusses effective communication in open source projects. It covers the importance of communication, common communication channels used in open source like emails and documentation, and tips for appropriate tone and sensitivity when communicating. Key points include: - Communication is critical in open source as projects rely entirely on written exchanges. - Channels have different purposes, features, and norms that should be understood. - Tone and sensitivity are important to avoid offense, and issues like rudeness, assumptions, and casual bias should be avoided in communications.
Communication in Open Source
- 1. Communication in OpenSource scott.wilson@it.ox.ac.uk @scottbw
- 2. What I’ll becovering in this session 1. Why is communication such an important topic? 2. Communication channels 3. Tone, appropriateness and sensitivity 4. Communication acts
- 3. 1. Why iscommunication 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 Sourceproject 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. 2. Understanding communication channels Communicationtakes place using communication channels Channels have purposes, affordances, and norms
- 6. Purpose Mark Anderson: TheLeadership 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)
- 7. Inbound, Outbound • Somecommunications 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
- 8. 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
- 9. Affordances Channels differ inaffordance - 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
- 10. Norms and Conventions •Channels often have norms. You often don’t notice it until someone breaks them – The multi-tweet – The 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
- 11. The Conventions ofEmail 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
- 12. Personal Preferences To whatextent 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)
- 13. 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
- 14. 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
- 15. ACTIVITY: What are theTYPO3 communication channels?
- 16. 3. Tone, appropriatenessand sensitivity We often contradict an opinion for no other reason than that we do not like the tone in which it is expressed.
- 17. A simple rule Don’tclick “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
- 18. Terseness Terseness is anatural 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
- 19. Adding context fornewcomers 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
- 20. 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
- 21. An example “First, let'splease 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
- 22. Creating a “criticismsandwich” 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”
- 23. Right message, wrongchannel 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?
- 24. Humour and sarcasm Humorcan 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)
- 25.
- 26. Diversity and Difference “Surface-Level”- Race, Gender, Age “Deep-Level” - Skills and personalities Graen, George B. - Dealing with Diversity
- 27.
- 28. 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
- 29. Debug these sentences 1."A committer should review his assigned patches according to this set of guidelines." 2. "When a user selects the function, she must then choose an option from the drop-down list” 3. "Shannon was hoping a lawyer would give his opinion on the licensing issue." 4. “Anyone committing code to the repository needs to check in his unit tests first” 5. “Last night a developer committed his changes to trunk and broke the build” 6. “This feature was added by a female developer at AnyCorp”
- 30. Professions and Skills Theadvice on groups applies equally well to professions as to ethnicities and genders Professional stereotyping – “Developers have no social skills” – “Developers don’t care about usability” Playing up to a role –“Speaking as an experienced developer, your code sucks” –“I’m a manager and I wouldn’t put up with…”
- 31. Accessibility and Usability Accessibilityand 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.
- 32. 4. Communication Actsin OSS
- 33. Communicating Identity and Presence Acommon type of paraverbal communication is how we communicate our presence online, or our presentity DeathDealer666 Perl Hacker and Evil Wizard Member: peoplewhohatecheese
- 34. Presentities: risks andrules • 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?
- 35. Whats in aname?
- 36. Speech Acts Inquiring Paraphrasing Acknowledging Advocating Speech actsare a way of categorising the content of conversations Summation Decision Unblocking Reframing Individual Follow Up
- 37. Unproductive Threads? • Argumentsthat 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
- 38.
- 39. 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.
- 40. Summing up • Communicationis a critical competency for working in open source • Understand the channels and what they are for • Use appropriate tone • Consider newcomers • Be considerate with criticism
- 41. 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