/talk-welcoming-people

Welcoming people, and other hard problems

Primary LanguageJavaScript

Welcoming People (and other hard problems)

Table of Contents generated with DocToc

Abstract

We interact with people in chat rooms, issue trackers, pull requests, discussion boards, meetups, hallways, or conferences.

How do we provide feedback constructively? Are we perceived as friendly as we think we are? How exactly do our cognitive biases unconsciously affect our interactions? How do we become conscious of them, and workaround them? What assumptions does our language carry?

Effective communication is particularly critical for project owners. As leaders, we open the doors to our gardens, and the first interactions define the tone for the group, shaping today’s atmosphere as much as tomorrow’s. In this talk, we’ll explore how to communicate effectively. Always, and with everyone.

Welcome, humans!

The major problems of our work are not so much technological as sociological in nature

Peopleware: Productive Projects and Teams (1987) - Tom DeMarco and Timothy Lister

We are humans working with humans to develop software for the benefit of humans

http://humanedevelopment.org/

Why diversity?

As professionals

Diversity is a learning opportunity. It makes us more capable of delivering a better product.

It’s not about adding diversity for the sake of diversity, it’s about subtracting homogeneity for the sake of realism.

https://twitter.com/MaryRobinette/status/545428674812465152

Examples

As humans

When someone has been discriminated against or is a minority, the status quo is in and on itself unfair. You need to lift people up, give them opportunities that you would not normally. If you are picking names out of a hat that's not sufficient because they are in the minority, they have less chance to be picked out of the hat. And so it does require you to change your mindset, and make an effort to reach out to people who are in a minority status in the group, and make sure they are included.

Chad Pytel, developer and CEO of thoughtbot http://betweenpipes.com/2015/06/25/Pytel-Fernandez/

On feedback

Implicit feedback

Feedback is about all the interactions you have:

  • what is NOT said
  • who is ignored
  • who speaks up
  • who stays quiet
  • who is invited

My work =~ Myself

Creative people often can feel that a rejection of their idea is a rejection of them.

New legacy code project. Do we criticize the code, the authors, or the system?

Let's not laugh at this code, and instead understand what we do not like about it and how to prevent it from happening in the future.

Work is a consequence of a negotiation of different restrictions, and feedback should take that into account.

Pixar’s “Plussing”

Rather than randomly critique a sketch or shoot down an idea, the general rule is that you may only criticize an idea if you also add a constructive suggestion. Hence the name plussing. Criticism meetings can be brutal, and this is where ‘plussing’ has played a game-changing role at Pixar.

http://www.thinklikeaninnovator.com/plussing-how-pixar-transforms-critiquing-into-creating/

This practice has been built on the core principles from improvisation, which are:

  • accept all ideas / don’t reject any idea
  • don't use “that will not work...”
  • don't use “yes, but...”
  • instead, use “yes, and...”

Once that new behavior is recognized as a required behavior, it can then evolve into a standard practice in the organization. But it must be required and practiced, first and foremost, by the leaders of the organization.

http://99u.com/articles/7224/why-fighting-for-our-ideas-makes-them-better

Good Feedback

Actionable, specific, and kind.

"You always do that thing that's bad for the group" < "When X happened you did Y, do you think Z would have been better?".

Encouraging, and within recipients scope of skills.

Every person knows something you don’t

Keeping this in mind will help you treat everyone with care, making them feel that they have a valuable impact to your project and community.

Onboarding to your Open Source Project

Informative website or README

“Landing page” for your projects. Should contain at least Communication channels, Installation instructions, Usage examples, Contributing guidelines.

Use labeled issues

Labeled issues

Do fast first code reviews

How To Improve Bus Factor In Your Open Source Project - Sumana Harihareswara http://www.harihareswara.net/sumana/2015/8/9/0

Measuring Engagement at Mozilla

https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g4435d357b_25

Slide 8

Most significant barrier to engaging in onramping others is unclear communications and unfriendly community.

Slide 26

Contributors who received code reviews within 48 hours on their first bug have an exceptionally high rate of returning and contributing.

Contributors who wait longer than 7 days for code review on their first bug have virtually zero percent likelihood of returning.

Showing a contributor the next bug they can work on dramatically improves the odds of contributing.

During code reviews

  • Try to respond to every question and comment
  • If you disagree strongly, consider giving it a moment before responding
  • Don’t assume people share your experience or context. Avoid words like “basically”, “simply”, “clearly”, “obviously”, etc
  • Also, feedback. We just talked about feedback

Flooding issue tracker? Don't worry!

Fat released Twitter Bootstrap and it was an instant success, and his "puppy" was suddenly a "dog" that didn't even fit in his appartment, and people were waiting on issues and pull requests, and anxiety OMG and guilt and everything!

Fat: What Is Open Source & Why Do I Feel So Guilty?

Canned responses for everyday interactions is a time saver and increases the chance we will respond respectfully to everyone. During the day and the week we don’t keep consistent stamina reserves; but we can keep prepared responses to common situations so that responses are positive.

Copy & paste a paragraph of text, press a button, and you took good care of an issue.

Situations we see often enough:

  • Issue is not a bug
  • Issue is specific to your app
  • Issue is stale and abandoned
  • Unclear request

All of these are detailed on the Maintaining Open Source Projects (Beta) book.

Patience with our brains

Our brain shortcuts make us efficient at saving energy but also make us arrive at illogical conclusions. We have flaws in our cognition, "low level bugs", and knowing about them we can adjust our behavior.

A cognitive bias is a pattern of deviation in judgment from which inferences about other people and situations may be drawn in an illogical way.

We'll see a few examples, and their application in our work in the Open Source community:

Online Negative Bias

Daniel Goleman, psychologist, author and journalist, identifies an online negative bias: the positive message you just wrote may be assumed to be neutral, and what seemed indifferent to you can be read as hostile by remote readers. Written discussions have less bandwidth than conversations over the phone or in person, and need to include more context.

As contributors and as reviewers:

  • Use positive language instead of neutral
  • Meet in person with your team, or discuss over video or phone whenever possible

Pygmalion effect / Chameleon effect / Unintentional mirroring

The Pygmalion Effect was studied in a training camp where officers were about to instruct a leadership development course for junior officers. A subset of the junior officers would become the next batch of leaders. The training officers were informed, based on ratings by previous commanders, which trainees presented “high”, “regular” or “unknown” command potential. What neither trainers nor trainees knew was that researchers assigned scores randomly.

Four months later all trainees took a test based on the materials they learned during the program. Researchers found that trainees whom the training officers thought had high potential scored better on the test than their “unknown” and “regular” counterparts. Being labeled as leaders resulted in actual improved exam results.

“The Cathedral and the Bazaar” (1999) is a famous essay by Eric Raymond on software engineering states in its 10th lesson:

SLIDE WITH QUOTE

Treat all your contributors as if they are the most valuable resource, and they will respond by becoming your most valuable resource.

Raymond’s lesson illustrates the “Chameleon Effect”: the human tendency to take on characteristics that have been arbitrarily assigned to us.

Welcoming behavior - Higher level

I recently pitched my talk to an older woman I know, and she half-joningly replied: "in the end we are all hypocrites, we say nice things but we don't actually mean them". I vocally disagreed, but it made me wonder: How many people are comfortable with contradictory lifestyle and morals? Is it most? And if it is most, does it make sense to try to change it, or should we just accept our flaws? Is our desire to make software communities more welcoming to everyone kind-hearted idealism, or a goal we can improve on?

And I remembered slavery

Slavery was a legal, sizeable business. Powerful organizations depended on it, and could enforce in court their right to trade humans. If I read the definition of what was common business you now freak out:

Now slavery is illegal in all countries, and when states violate this principle the International Labor Organization prosecutes them in the International Court of Justice. The US Senate has recently passed a resolution apologizing to African-Americans for the “fundamental injustice, cruelty, brutality, and inhumanity of slavery”.

And I remembered women’s suffrage

Women's right to vote proponents had to change collective consciousness once. Now many countries have had female presidents for years.

There are still other rights to pursue, but women’s vote is today as significant as any other person in society. A step forward.

And I remembered same-sex marriage

And I remembered salary gaps

Which is more of an ongoing discussion.

Common knowledge

It might not be their opinions that change, but I'll argue that "common knowledge" of those opinions are what triggers the changes.

There is common knowledge of a fact when in a group:

  • everyone knows the fact
  • everyone knows that everyone knows the fact
  • And so on

Soviet handing leaflets example

A soviet stands in the Moscow train station, handing out leaflets to everyone who passes by. The KGB arrests this person, but they discover that the leaflets are blank pieces of paper, and they demand:

  • “What’s the meaning of this?”
  • “What is there to write?” he replies, “It’s obvious!”

The man is trying to make common knowledge something he assumes his “readers” already know.

http://www.scottaaronson.com/blog/?p=2410

"Naked emperor" example

https://en.wikipedia.org/wiki/The_Emperor's_New_Clothes#Plot

Consequences

Stating something publicly (even when obvious) can change how a group of people feel and behave. Until an announcement, it’s possible that not everyone knew that everyone knew the thing, and that can prevent individuals from acting.

As a dictator, to prevent something from becoming common knowledge, all you need to do is censor the common-knowledge-producing mechanisms: the press, the Internet, public meetings, the #talkpay Twitter thread.

"Unwelcoming behavior is not ok", and that is common knowledge

We all know many concrete unjust situations in our organizations, and we want to change them. This is common knowledge at least for Open Source and Feelings participants (not only in person, but also Twitter, Confreaks, and elsewere).

  • Let's carefuly talk about salaries
  • Let's carefuly talk about microagressions
  • Let's talk about gender and race ratios in our teams

Like slavery moved from a “that's how the world works” into an awkward “I swear I grant my employees all their rights (I even pay them fairly!)”,

Let's make it common knowledge the fact that gender, or race does not affect the value of our work, the opportunities we get, or the recognition or salary we should get.

Let’s keep calm, and have these now difficult conversations.

Resources