Although we all work towards common goals, there may be reasons that we dont always agree * Clash of personalities – some factors of peoples' background may mean that they dont get on * Disenfranchisement – some people feel their views aren't given the weight they should have * Arseholes – Some people are intentionally unpleasant or divisive, for some reason
Differences in peoples' backgrounds or personalities may cause friction with other people. In a FOSS project you dont know much about who you're working with, so it's important to be sensitive to this diversity to avoid upsetting people, or getting upset yourself
* Young people tend to be more gung-ho with new ideas, older people can be more cautious and not “move with the times” * People of different ages have different points of reference, different ways of communicating
* Different countries, religions, nationalities have different cultural norms * Inviting someone from a culture where alcohol is forbidden to talk over a beer probably isn't appropriate * A one-off misunderstanding is unlikely to cause an argument, but persistent ignorance and insensitivity to such issues may breed animosity. * Avoiding local in-jokes and colloquialisms is also important – those outside may feel excluded
* Some people have more opinions than others * Those who always express an opinion may appear arrogant to those who dont * Those who seldom express opinions may appear disinterested to those who always do * It's important to express an opinion as a point of view with justification, not as the one true way
* Not everyone is the same, and sometimes people just dont get along * Some people find it hard to empathise, and may offend others without realising it or understanding why – they require patience!
* Projects will generally have a standard language for communications (often English) * If this isn't your first language you may have trouble with grammar and syntax, and not say what you mean. * Even if it is your first language, most communication is text-only and asynchronous, while we learn to communicate in person, with body language and vocal cues. Mood, tone, and sarcasm are hard to communicate via text. * If you read something that appears terse, re-read it to check that you haven't misunderstood, and ask for clarification before getting upset. * Before you send something, check to make sure that it's not likely to be misunderstood
* People may feel their views aren't considered by the projects leaders * This might be justified, e.g. they haven't contributed to the meritocratic process. This needs to be explained sensitively. * Commercial sponsors may have plans for a project which some members of the community dont support * Volunteers on a project may feel they are taken less seriously than employees of a sponsoring company * All communication regarding a project should be done in the open to mitigate the feeling that decisions are being taken in secret. * Engage with feedback from the community * Possibility for tension here - how do you open up to the community while keeping things secret for a "ta-da" moment * Canonical attempted to balance this with the Ubuntu Skunkworks initiative, bringing community members in on internal projects * In practice this ended up with Canonical having more managed-but-open projects, rather than closed projects with community contributors, such as the Ubuntu Touch core apps. * There needs to be a variety of channels for people to provide input to avoid barriers * These channels can also be useful records when resolving conflict - if an idea is brought up that has previously been decided against, the archives of communication channels should contain the discussions which can be referenced. * Channels need to take temporal dislocation into account
* Some people will just want to be dicks. * Not only creating negative feeling and dissent, but encouraging others to join in. * Need to be countered with evidence, not with words. Show them to be incorrect in a calm and professional manner. * At some point, if you've determined their behaviour isn't going to improve, it might be time to tell them to go away. * Does their dissent outweigh their contribution? * How can you stop a volunteer from volunteering? * Technological means - remove them from discussion lists, revoke commit access * Having a well-defined code of conduct can make justification and implemention of this process easier.
* Learn to identify conflict before it happens * Know your community, its members and their relationships * Some people will be more inclined to conflict than others * Spot a discussion which might give antagonisitic people an opportunity to wind others up, and be prepared to deflect such behaviour as soon as it surfaces. * Dont feed the troll * People make mistakes - these need to be pointed out in a constructive way so the person can learn from them, and then forgiven * Use a code of conduct to make it clear subjects which are considered off-topic, particularly politics and religion
* There may be reasons why people are behaving in a certain way. Speak to them before deciding they're just being difficult, as they may not even realise. When they realise that they're being abrasive or upsetting people, they may adjust their behaviour to fix the problem without the need for further intervention. * Such conversations should be conducted as a friend not a leader - not a performance review or scolding. * They should always use a syncronous Audio/Visual medium, this allows for greater sensitivity, and elimiates the risk of misunderstanding. * If the conflict is in public, leadership need to be seen to dealing with it so that the community gets a sense of justice.
Destructive: • one person has to give in too much (win-lose) • the dispute hurts a relationship • there is no agreement reached • there are uncontrolled emotions, anger, and raised voices • the conflict prevents or stops people from working Conflict is constructive when it: • leads to resolution • builds a strong relationship with improved communication • opens people up to new ideas • leads to a win-win resolution • develops common goals • clarifies a problem situation and leads to positive change • Which was easier to discuss and why? • What surprises did you find when the entire group reported out? • How do you think most people at work feel about conflict? • What are the lessons you learned from this activity?
1. Collect data - Learn what the conflict is about, and develop an objective picture of all parties’ perspectives. 2. Probe - Ask open questions, listen, and engage with all parties to get the full story. 3. Save face - work toward a winning resolution for everyone, and try to avoid embarrassing either party while always remaining objective and unemotional. 4. Discover common interests - Finding common interests and alliances will help find points of commonality beneath the conflict. 5. Reinforce - Where both parties share a perspective and agree, reinforce those perspectives, and particularly try to use data to back it up. 6. Negotiate - Start simple, trying to get both parties to agree on simple solutions, and then continue to build toward the common goals of both parties involved. 7. Solidify adjustments - Review, summarize, and confirm the areas in which both parties agree.
* When a conflict arises, it can be resolved by the participants before it gets out of hand * This can avoid damage to relationships, and allow work to move on more quickly than if the conflict was allowed to escalate. * Steps: * Establish the cause for grievance * Establish the party with the power to resolve the issue * Agree on a cause of action that resolves the grievance * Review the situation to ensure the situation is resolved * Key points: * Take one another's views seriously * Focus on your common goals * Be polite, dont use inflamatory language, dont take things the wrong way * Take your time in ensuring your point is made clearly and understood * Be open to compromise if it helps achieve your common goals
1. separate the people from the problem * The cause of conflict is often down to different perceptions of facts * Encourage both parties to put themselves in one anothers's place * Parties should not assume the worst, nor blame one another for the problem * Each side should try to make proposals that are appealing to the other * Conflict and negotiation can be emotional * Emotions should be acknowledged, and their cause identified * One party dismissing the feelings of another is likely to escalate the emotional conflict * Apologies and sympathy can help diffuse emotional conflict * Managing communication * Parties may not be used to communicating with one another * They may not be used to the communication process, so focus on what they have to say rather than listening to one another 2. focus on interests rather than positions * Positions are what you have decided upon, interests are what led you to those decisions * Conflict is caused by opposing positions - resolution based on positions means someone will lose out * Identifying the interests behind each position helps find an alternative position that suits both parties * Parties must explain their intersts clearly if they want it to be taken into account by others * Each party must keep a focus on their interests while being open to new positions 3. generate a variety of options before settling on an agreement * Parties may have a narrow view of the options available * Parties may have decided on an option before considering other available options * Parties may view all options as win/lose * Separate invention from evaluation of options - encourage wild and creative brainstorming of ideas, the most promising of which can be identified and refined later * Focus on shared interests can break the win/lose mentality - Low cost to you, high benefit to them. 4. insist that the agreement be based on objective criteria * Base decisions on verifiable facts. E.g. decisions over a choice of technology should be based on studies/benchmarking that both parties have faith in, not personal preference or flame wars * If a party will not agee upon substatiative criteria, then focus on procedural criteria * Proceudural criteria may be an agreed upon process, E.g "You cut, I'll choose"
1. Calm and reassure * Set the tone, dispel agression, make it clear that you're committed to resolving the situation. * If parties have strong negative feelings towards one another, this should be done on an individual basis before bringing them together. 2. Get the facts * Ask for both sides of the story * Work through the chronology of events, asking for more detail where needed * Dont offer opinion or emotion, dont take sides * Ask for each side to provide evidence of their account * Gather additional data from archives, logs, blogs etc. * Consider getting a third party points of view, especially where the wider community has been affected. * Can be done directly, or by a wider call, but needs to be managed carefully * Establish an objective view of what happened * What went wrong? * Have the rules or expectations of the community been broken? * How could the parties have handled the situation better? 3. Discuss * Hold a meeting between the participants - public meeting if the conflict involves the wider community * Real-time, fixed length * Introduce * Clarify ground rules * Focus on mending relationships and avoiding future conflicts, not trying to undo past mistakes * Discuss the issues accepting input where appropriate * Discuss issues one at a time, focusing on areas where participants agree rather than disagree, reaching consensus where possible * Participants will have some principles in common - belief in FOSS, belief in the software's goals, start here if no-where else. * Take notes and make sure everyone understands what's been agreed * At the end of the meeting, schedule the next one to ensure a sense of continuity 4. Document * Codify all agreements, with careful use of language, and ensure that participants agree on wording. 5. Reflect and maintain * Check in with participants to ensure that agreed actions are being taken, rules are being stuck to * Provide validation as participants reflect on their conduct and progress, but let them bring reflections to you, dont draw them out
TYPO3 Communications Workshop: Conflict and Resolution
Conflict and Resolution
In this session
Why does conflict happen in a community?
Resolving Conflict (Yourselves, and with the help of
3 People in your group take a piece of paper from the
envelope, read the instruction but don't tell the rest of your
Throughout the following discussion, stick to your
instruction unless you can be convinced not to.
If you don't have a piece of paper, just be yourself, and try to
work out what is on each person's paper.
Your project is going to start using “codenames” for releases.
Decide on a naming scheme for these code names.
(e.g. Ubuntu uses “Adjective, Animal”. Fedora's names must
relate to the name of the previous release. Mac OSX used
breeds of big cat, and now uses places in California)
Reasons for conflict
Clash of personalities
Poisonous People / Pessimists
Clash of personalities
Clash of personalities
I remember when all this
was punch cards
OMG NOSQL FTW!
Clash of personalities
Let's discuss this over a beer!
Clash of personalities
Git is better than Subversion!
Python is bettter than Ruby!
Iron Maiden are better than Metallica!
Not listening to everyone's views
Putting commercial sponsor's needs first
Volunteers vs. Employees
Someone decides to be intentionally disruptive
This other people are convinced, and follow the pattern
This may lead to splits or forks
Must be countered with evidence – Don't feed the troll!
Know your community
Learn to spot clashes of personality
Defuse conflicts before they happen
Accept that people make mistakes
Once identified, forgive and move on
Avoid discussions in inflammatory topics, use the Code of
Conduct to kill them early
A person may not realise their behaviour is causing conflict
Chastising them could lead to alienation – speak to them as
a friend, not a leader
Synchronous media is key
If the conflict was public, the outcome should be too
Conflict can be Constructive as well as Destructive.
In pairs, brainstorm completions for the phrase “Conflict is
Now, brainstorm “Conflict is constructive when...”
The conflict resolution process helps us turn a destructive
conflicts into constructive ones
The Resolution Process
Participant – Driven
Participant Driven Resolution
Establish the cause for grievance
Establish the party with the power to resolve the issue
Agree on a course of action that resolves the grievance
Review the situation to ensure the situation is resolved
Elliott, M., & Scacchi, W. - Free software development:
Cooperation and conflict in a virtual organizational culture.
1. Separate the People from the Problem
2. Focus on interests rather than positions
3. Generate a variety of options before settling on an
4. Insist that the agreement be based on objective criteria
Fisher, R. and William, U. - Getting to Yes: Negotiating
Agreement Without Giving
1. Separate the people from the problem
2. Get the facts
5. Reflect and maintain
Read the “Project Banana” case study and discuss in your
What should the project do to resolve the conflict?
Bacon, Jono. (2009). Art of Community O'Reilly
Fisher, R. and William, U. (1983). Getting to Yes: Negotiating Agreement Without Giving In
Lambert, J and Myers, S. (1999). 50 Activities for Conflict Resolution – 2 Activities HRD
Elliott, M., & Scacchi, W. (2004). Free software development: Cooperation and conflict in a
virtual organizational culture. Free/Open Source Software Development, 152-172.