Ted's notes (@thesleepyvegan)

Mike Moore (@blowmage)

• model of mastery
• rubocop (or similar) helps resolve disputes about style easily
• the box: experiencing other people or circumstances as having more power over other people than we do
• get good at working remote
• most important point: truthful honest assessment of yourself and your abilities

André Arkin (@indirect)

• inclusivity is more important than diversity
• illusion of a meritocracy
• not a pipeline problem
• if your reason for diversity isn’t to include people, you will never get it. economic arguments for it teeter on exploitation
• including people is an attitude and philosophy of (social) interaction

How to include end users:

• code of conduct — great example is contributor covenant. create a safe space for people
• documentation — write docs aimed at newcomers. use she/they for your pronouns. https://jacobian.org/writing/great-documentation/ tutorials, topic guides, an API reference (useless for newcomers!), troubleshooting docs. links to docs in error messages
• accept issue reports gracefully — huge indicator of how inclusive your project is. start with the idea whatever the reporter says makes sense to that person.
• if you have a support org, be as accepting and open of bugs coming from support to engineers as they are the voice of your users * listen and speak respectfully. anyone representing your project should not harass or be condescending. enforce code of conduct on everyone regardless of how 'invaluable' that jerk is

Including contributors:

• ask people for help in order to include them. contributors do not need to be an expert to help! maintainers especially need newcomer perspectives to understand how to help.
• as a maintainer, be open and honest about what's hard. André mentioned spending first two weeks on Bundler saying "what?! how?! why?!"
• pairing with contributors!
• write developer documentation. TOTALLY DIFFERENT from end user docs. how to get started contributing, how to run tests, criteria for accepting PRs, how to contact people, write a release guide, etc. every project should list things they welcome, eg, typo fixes welcome!
• pull requests are just issues with work done for you. if you need to reject a PR, be gracious: "thank you, i want to understand this and know how to solve your problem in a way that works for everyone"

Apply all of the contributor guidelines to team members. Give positive feedback and ask for help when you need it.

Underlyng principle: respect and empathy. Thinking about how you'd like to be treated is not enough. Think about the context those people are in and what they're struggling with.

Tech is a biased field and only the people in tech can change it!