I'm at communications at the e-book company, and he has very much dived into how communities of software developers work and how they can be built.

He's been at an initiative advisory board, which is an initiative to support women in open technology and culture. And now recently he has been elected as president of the library

and information technology association. Yes, now that's your turn. All right. So the title of the talk today is linked to open community. There's a bibliography

and a PDF of my slides available at Andromeda Yelton dot com slash talks slash swib 16, which I just tweeted out on the conference hashtag, so if you just want to click on it instead of typing in my extremely long name, you can do that thing and follow along.

So I was asked here to talk about inclusion in tech communities, and I asked in my abstract, they say build it and they will come, but what happens if you build it and they don't? Anyone who's ever tried to get contributors involved and sticking around over the long

haul with your open source project knows that it's not necessarily easy to do. And so I'm going to talk over the course of this talk about ideas and strategies that people have come across in trying to include more and more diverse people in their conferences, their open source projects, et cetera, and hopefully you will come away with some ideas

that are of use to you. So the sort of overarching theme that I'm unifying things with is the idea of inclusion as interfaces. Any time you have a project or a conference and a person, there's a boundary between the person and the project,

and that boundary may be more or less easy to navigate, more or less turbulent, as here when you have the water crashing against the rocks and sometimes you end up with some chaos at that border. Interfaces have also been really relevant

to me this week because here I am in a country I have been to only once, 25 years ago. So there are a lot of unfamiliar interfaces for me now, starting with the fact that my German basically extends to please thank you and the girl is hungry, which are useful for me but don't actually get me very far. And so I've been thinking about what aspects

of being here make it easier or harder for me to navigate. The fact that essentially everyone has dramatically better English than my German is very helpful, even if it

is a public transit system in the world has its own completely unique ticketing interface that makes no sense. It literally took me half an hour to figure out how to buy a train ticket yesterday and it kept telling me that I was wrong but it was telling me in German so I didn't know how to fix it. Anyway, so the question of what

makes it easier or harder to navigate a space that's totally unfamiliar to you is very much on my mind this week. I'm going to talk about three basic categories of interfaces that a person can have with a culture or a project and the boundaries between them

honestly are not really clear boundaries. I could have chosen to put things in various categories but the basic types of interfaces I'm going to talk about are infrastructure, governance and culture. Infrastructure is basically what things do you have that contribute to. Contributors need to work with as they set up your project or contribute to your

project. Governance is what sort of rules do you have for how people behave in the space, what the leadership can and can't do and culture is culture. So let's talk about that. Let's start with infrastructure, the stuff you have that people contribute to or that they use in order to contribute. Examples of infrastructure you can have that

make it easier to include people. Above all, you need tools to support decision making and that might be for leaders of a project or that might be for contributors to a project.

So in terms of leaders, Mozilla has done a lot of research on contributor retention and they're in a great place to do that since they have this enormous world-spanning project with tens of thousands of potential contributors and they get to employ statisticians and stuff. And what Mozilla has found is the single most important factor in whether

someone comes back and contributes to Mozilla long-term is does someone respond to them within 48 hours? If they submit a pull request and they get some kind of response inside of 48 hours, they will probably come back and contribute again. Even if that

response is just I saw your pull request, I'm really busy, I can't review it for a few weeks and I'll get back to you, that's good enough. They literally just need to know that someone is paying attention and someone cares. And then if you can get to

them at some point within days 2 through 7 with a suggestion as to here's what to do next, that also increases the chance they'll stick around. If they don't hear from anyone within a week, they will never come back and you have just lost this contributor forever. So leaders need tools that help them make decisions like that. They need

an easy way to keep track of what's in the queue, what has come in recently, what's our response time, can we monitor how quickly we get back to people? So they can keep track of that. Contributors also need tools to support decision making. Mozilla has also

found the vast overwhelming majority of people who are going to contribute to their code base do so within 24 hours of making an account. There's a really long tail, there are people who make an account and don't contribute for a year, but overwhelmingly people who contribute anything are going to do it within that day. So you need a way

to capture their enthusiasm and make it really easy for them to make a decision about what to do. One example that a lot of projects, including the Django Python based web framework has is an easy pickings tag. So if your issues queue has some tag along the lines

of easy pickings, that tells contributors who may be new to the project that this one is relatively simple to get into. As you know, some places are really hard to contribute to a project, you have to be an expert in things, they're not good for newcomers, but some are pretty straightforward. They may even be things like clean up the documentation

that don't even require knowledge of code, that just require someone who speaks the language reasonably well to go through and make sure a section makes sense. So tags and other metadata that make it easy for contributors to tell, like do I have the skills to make this contribution, where can I go to find something that's doable and interesting

is really helpful. So make it easy for your potential contributors to tell where they can be a part of things and make it easy for your leaders to tell if you're actually being successful at doing that. Other infrastructure that I almost listed

as most important, because it is dear to my heart, is documentation. Documentation is a form of hospitality. Explaining to people how do you install the code or how

do you use it as an end user or what are the guidelines for contributors or any of the other things that people might need to know, explaining that clearly is a way of being hospitable to people and showing respect for them and making it easy for them to do stuff. Even if you have tagged your project with different ways people can contribute,

if they don't have an explanation of how the tool works or what style they're expected to submit code in or any of that, it's unnecessarily challenging for them and they spend a lot of work on things that are not being a part of your project or your community and they get frustrated. There's a really great series of blog posts written by Jacob

Kaplan Moss on documentation and again all of this stuff is in andromedyelton.com slash talks slash swib16 that I tweeted on the conference hashtag so you can go follow up the specifics if you like. But he's got this great series of blog posts on how you

write good documentation and he was one of the founders of the Django project which has amazing, amazing documentation. I'm actually primarily a Django programmer and I learned that because somebody needed to be at a previous employer and everyone else was busy and I

was able to learn to be a Django programmer because their documentation is amazing. There's an incredible tutorial and everything you might need to know is really clearly explained somewhere on the website and so that made it possible for me to get up to speed. Anyway, so Jacob Kaplan Moss says there's basically three different types of documentation your

project needs to have. It needs to have a quick start, so some sort of tutorial where people can experience success over their lunch break. Obviously you're not going to teach them everything they need to know but you want them to be able to get your project up and running and do something interesting inside of half an hour because that's going

to give them that sort of thrill of victory and convince them that this is a useful bit of software to work with and this way lies hope. So that's your quick start. You need a concept guide that explains sort of in depth what are the different things, ideas,

components in this project, why are they there, why did we make the kinds of decisions that we made, something that helps people understand the why. And then you need an API reference. You need the thing where obsessive people can go look up what are all of the arguments that this function takes and what does it return because sometimes people just need

to know that stuff. But one of the critical things is these are all different pieces of documentation and they have different audiences. The person who needs the API reference is the expert programmer, you know, the developer who's planning to contribute, the person who is making a custom local installation of your project and who has a lot of tech

skills, the person who needs the quick start is someone who may or may not have significant programming skills, they're someone who's new to your project, they're spending a short amount of time on it, deciding if they want to spend more. These are different people with different skills and different goals. And so you need to have different documentation

for all of them. Jacob Kaplan Moss also has some great pointers on style, like how do you develop a good voice for writing your documentation, which is not easy. So I recommend checking all that out because it's great. And there's also actually a conference called Write the Docs, if you find yourself really liking documentation. I think it's

in Portland, Oregon in the U.S. every year. And this actually grew out of the Django project because Django's documentation was in fact so good that it spawned a conference about documentation. So if that's your thing, there's a whole community of people there who love it as much as you do. Okay, other things infrastructurally that people have

done to help get people involved is the Wikipedia Teahouse. This is a project that grew out of Wikipedia's gender gap efforts. As you may know, Wikipedia is fairly overwhelmingly slanted toward male contributors. And Wikipedia has also had a number of problems over the

last decade with retaining editors for a number of reasons. And so they've tried some things to sort of broaden participation, reach out to more people, and maybe have them stick around longer. And the Teahouse is one of those efforts. And it's a site on the English Wikipedia where basically new people can go and ask questions and get help. And

it's kind of this weird mind-bending wonderland, actually, because if you've ever spent much time on English Wikipedia, you've probably run into places where people are having these just like really unpleasant discussions and being super mean to each other. And then

you go to the Teahouse and someone asks a question and someone is like, thank you for asking that question. Let me patiently explain to you the answer to it. I hope this worked for you. Please ask again if you have more questions. You're like, well, what just happened? Why is everyone nice? So the Teahouse is great. And clearly it's helpful for

beginners in that they can go and ask those questions that maybe they would feel stupid asking and not merely get an answer but feel a sense of trust that people are not going to be mean to them for not already knowing the answer. Wikipedia Teahouse is also great in that it's on the wiki, right? So it uses the

same interface as the wiki and it has some of the same cultural norms as Wikipedia in the sense that all the content is open and there is publicly available history. So it's culturally part of Wikipedia and it's

technologically part of Wikipedia but it provides a much gentler on-ramp into the whole experience. So people can sort of get accustomed to those norms that may be unfamiliar with them. You know, working that openly may be really new to some people. They can get used to that but they can get used to that in a way where there are hosts who are

specifically tasked with being nice and helpful. They can get answers to questions that they may need to have answered before they can do anything else on Wikipedia. And then the tagline for Wikipedia or the Teahouse actually says, you know, welcome to the Teahouse, a friendly place for, you know, whatever,

asking questions. So it's branded really consciously around being welcoming. And Wikipedia has done some research on the Teahouse's impact on editor retention and it seems to be useful. Again, I have links to all that research on my website. So you can check that out. And then another open source

project that has done a couple of things that I really like in terms of providing infrastructure to make it easy and welcoming for people is Dreamwith. I don't know if this is familiar to many of you. Were any of you on LiveJournal back in the day?

Because I was. All right, awesome. So basically this is unfamiliar to the entire rest of you, but LiveJournal was a journaling thing that if you were possibly like an emo teenager circa 2000, you may have been on. And then like politics happened as they do and Dreamwith split off from LiveJournal.

LJ had an open source code base, so Dreamwith forked that and created a new journaling community with sort of aimed at a different portion of the site, a different population of users and with a slightly different set of features. And

they made two big decisions in splitting off from LiveJournal that affected their culture going forward. And they're still around. I mean, this came out of stuff that happened, you know, 15 years ago, but it's still totally in existence. So one of the big strategies that they made is to speak openly with their users.

They clearly were very influenced by the whole Cluetrain manifesto, market speak in human voices idea. And they were also very influenced by the fact that LiveJournal at the time, when there was something like a site outage, just kind of didn't tell anyone what was happening until after they'd fixed it.

By which point, of course, all of their user base had started like swearing and setting things on fire because things didn't work and they didn't know why and they were really frustrated. So Dreamwith made a decision from day one to be open with their users and to say, like, what's going on, even if all they

could say is, we know there's a status outage, we're working on it, we don't know why, we'll update you. And the result of this is roughly paraphrasing from one of their internal logs that they made public. They found, I think this is the only website in the universe where when things break,

people actually apologize to us for reporting it. Their users trust them so much that their users are like, I'm so sorry, but if it's not too much trouble, can you please fix this thing that isn't working? I feel really bad about making your day harder. I love you. Yeah, I mean, this is probably not

how you're used to website users behaving, but it turns out that when you respect people's feelings and you respect their desire to understand and be involved and you communicate with them in a way that's human

and respectful, they respond by caring about you. So that was great. And then the other big decision that Dreamwith made was to actually slow down the deployment of their open beta in order to spend some time building

the community rather than the code base. So they could have gone into open beta at least a couple of weeks earlier than they did if they had just sat down and put their heads down in the code for a few weeks. But instead, they decided to have more people working on the code.

Instead of having the two core people just buckle down and finish it, they made sure to have a much bigger group of people working on those issues, which took longer, but it meant that they had a core group of contributors from the very beginning who were invested in the project, and that gave them the chance to be sustainable in the

long term. You can't rely long term on one or two main contributors making your project work forever, because eventually life will happen or they'll get burned out or they'll get interested in other things. You need to have enough people involved that you can have new leadership step up over time, that they can do outreach to new members.

So they slowed down their deployment to let more people work on it. And they also spent that time on things like documentation, as mentioned, and coming up with this thing called DreamHack, which basically was an easy installation. It was a hosted installation.

So if people wanted to contribute, well, if you want to contribute to an open source project, what's the first thing you have to do? You have to get it up and running on your machine. That may be easy or that may be really hard. In the case of DreamWid, at the time, it was really hard. And it actually relied on some outdated versions of dependencies, so people were having to like break their systems to make things work.

And that made them sad and people would give up. And if they give up on the installation process, there's no chance that they can do anything more sophisticated. So they actually built a hosted installation where if you wanted to play with it, you had this sandbox you could just go get. And that made a tremendous difference to their ability to onboard

new contributors because it removed this obvious source of frustration. There's a great Code for Lib Journal article by some people at North Carolina State University that says basically you should time things like this, right? Like if you're a developer

at a fancy library that has a whole team of developers, there's a lot of things that are easy for you that may not be easy for the people that you want to have using your code or developing your code and things that are easy for you may not be easy for someone who's the only developer at their library or someone who is not a developer

who maybe has some great command line skills and has some some ability to install software, but doesn't know how the code works. So in the NCSU article, what they did basically was they went out and they found the target users of their software and they asked them to perform various tasks like

get this up to a working installation on a laptop or pilot a deployment. And they had a stopwatch and they saw like, how long does it take? You know, days, hours, minutes. The lower those numbers are, the more people are going to end up

being involved, again, because the annoying upfront hurdle is minimized. So they're actually able to spend their time on using your project, contributing to your project, fun stuff, other than installing dependencies, which literally everybody hates. So they invested some extra time upfront in these things,

and it paid off long term in terms of sustainability and community building. So what this means really is that the most important project infrastructure, it's not actually any code that you have in a project you write. It's everything else. The infrastructure that makes it easy for people to be part of your project

and part of your community is the documentation. It's the tutorials. It's the fact that your install process is easy and well documented and hopefully relies on standard tools. If you're working in Python, make it possible to use PIP to install your project. You know, look at Homebrew, whatever the standard

sort of installation path is for the language your project is in. Like, let people install it using that thing. You know, think about what are the actual tech skills that it takes for people to contribute. Does that match with the tech skills

you want people involved in your project to have? You know, if you say you're building a tool that non developers can use, set some non developers down and see if they can actually use it. Because if you are a developer, you can't tell. I promise I'm a developer and I can't. Contributor guidelines.

You know, if people want to show up and write code or write documentation or run a workshop or something like that, have you written down anything they need to know before they can do that? You know, is there a style guide? Is there a contributor license agreement, which I'll mention more later? Do you follow just basic software best practices, right? Do you have a test suite

so that if people write code, they can tell if it broke your stuff? Have you actually written down what all the dependencies are and what versions they all are? Because I have tried to install a project that wrote down its dependencies and none of their versions. And it was really, really annoying. Everything other than the code is the stuff

that makes your project easy for people to approach. All right, governance. That's all stuff that's mostly about contributing in terms of code. But governance is more about we're all people and we interact as people and we come together in physical spaces and virtual spaces.

And what kind of rules might we need to make those interactions work out? What can our leadership do and not do as well as what our members do and not do? So I mentioned contributor license agreements. Project Hydra, which is an open source repository project,

goes very strongly into contributor license agreements. And they have a section on their wiki that explains why they do that. And Bess Sadler, who's one of the leaders of that project, gave a great Code for Lib talk in, I think, 2013 about building a commons, creating a commons. And one of the things she said is that

your project needs to be understandable to the lawyers in some sense. It's kind of annoying, but having a contributor license agreement where contributors have clearly given you a license to that code, puts your project in a much better legal situation in case anyone challenges it later on.

And also some people's institutions may require that your project have some sort of clear license in order for them to let their people work on it. You know, institutions have lawyers and they care about these things whether or not you do. So it may be important to have a contributor license agreement.

On the other hand, the Software Freedom Conservancy, which supports lots of open source projects, says really you don't, in most cases, need a contributor license agreement because it serves primarily to annoy people, sort of like an extra hurdle that gets in people's way. So there's pros and cons,

but it's worth thinking about whether you need... You certainly should have a license for your project, but then whether you go on to have your contributors sign a license or not, may or may not be the best thing for you, but you should think about it and make that decision consciously. Moving on to more sort of in-person things.

Incentives to bring a friend. If you want people to come to your workshop, your conference, whatever, especially if you want new people to come, one great thing you can do is give people discounts or other incentives if they bring a friend with them.

This is something that the Boston Python workshop did. They taught beginner-friendly workshops to women and their friends. So the idea there was they wanted to increase gender diversity in the Python community, and so they had workshops that were primarily aimed at women, but people who are not women could come if they had a friend

who was a woman that they came with. So it makes it... It achieves their goal of gender diversity while also, you know, sort of being more friendly. Software Carpentry similarly will, for some of its workshops,

give people discounts if they come with friends, not necessarily with any gender restrictions, but discounts if they come with friends. And the idea behind that is that entering a new sort of community or learning a new tech skill can be really intimidating, and if you show up with a friend, you will not feel as intimidated because when you feel intimidated, your friend will make you feel better.

The idea is also that you'll just have better feelings associated with the experience, you know? If you go to a workshop on a new skill and your friend is there, you have now had an experience with your friend, and you have all these positive friend feelings associated with it, and that will make you more engaged

with whatever you just learned long-term. So this is a strategy for attracting like new people, and particularly people who may not yet have the skills to fully engage with your project. If you want to bring in experts from maybe populations

that haven't been well-represented in your project before, the sort of best practice there is do a lot of outreach, and then do blind review if you're asking people to submit, you know, conference proposals, journal proposals, things like that. There was a great article, How I Got 50% Women at My Gaming Conference.

If you're at all familiar with like gaming, you know that you do not get 50% women speakers at your gaming conference. This never happens. But this one conference organizer did, and the way she did it, she went out to basically like all the women she could think of, and this is time-consuming, right? Try not to be the only person doing it. It is really, really time-consuming to do this outreach stage.

But she went out to all of them, and she's like, hey, I'm running this conference on games, and I know that, you know, you're doing some interesting work, and I really hope you'll consider submitting a proposal, and they were like, oh, no. I don't actually know anything about anything. This will basically always happen if you ask women to submit conference proposals.

They'll be like, oh, no. I don't know anything about anything. And then she'd be like, what about that one thing that you did? And she'd give them like an example of work that they were doing, and they're like, oh, yeah. I guess I do know stuff about that. This is funny, actually, because Christina asked me like, hey, you want to come and talk about inclusion? I'm like, I don't know anything about that. Like, all these other people are doing way more work on it than I do.

I don't know anything about that. And then 30 seconds later, I'm like, wait, I just thought of like eight projects off the top of my head that I know that people are doing that are really cool. Never mind. Okay, I'll come and talk to your conference. So you actually may have to tell people that they know what they're doing because they may not realize it, especially if they're underrepresented in your community.

If they look at your community and they don't see anyone who looks like themselves in some way that is important to them, they may think they just like don't belong and have nothing to say. So you may have to remind them that actually they're the only ones on earth doing this really cool thing that they kind of forgot mattered. But then when you actually review the proposals,

make the review process blind if at all possible. Because no one wants to feel like they're a token, right? No one wants to feel their proposal only got accepted because they're a woman or they're black or whatever. Like, people hate that. You want to accept the best proposals that you get.

And this is a great way to make people feel like the process is more fair, but it's also a great way to accept proposals you would not have otherwise accepted because it's really easy if you know the names of everyone to be like, oh, yeah, that person. Like, they always talk, we know their work is good, and accept them instead of someone lesser known who may actually be doing cooler stuff.

So when this Courtney, whose last name I have totally forgotten, Stanton, Courtney Stanton did this for a games conference. She ended up with 50% women speakers not having any idea who the women were at the actual review stage, right?

It turned out, in fact, that her application pool was only 33% women. It's just that the women only submitted proposals if their talks were actually really good. And they had a lot of terrible proposals for men that they rejected at the blind review stage. This approach has been duplicated by JSConf in Europe.

And the Python Software Foundation does something similar for outreach for their speakers. So this is a thing that works if you're willing to sink some time into it. All right, I have enough other things. I'm going to have to pick up some of the pace on them, I think. All right, the Recurse Center, it used to be known as Hacker School.

It's like a three-month programming residency in New York City that is really cool for a lot of reasons that I don't have time to get into. But one of the things it's known for is its social rules. So it has four social rules that everyone is encouraged to follow and enforce

in order to make their space more welcoming and in order to recognize that the people in their space are all working on things that are, you know, new to them. And that's exciting but also challenging and scary sometimes. Rule number one is no feigning surprise. So you know that thing where someone is like, oh, wow, like I've never worked in Ruby before.

And you're like, you've never worked in Ruby before. Like, who are you? That happens a lot in tech and it's actually really terrible because it makes people feel stupid. None of us know everything there is to know in technology or in libraries because they're all way too big.

So, you know, it's best if you don't act like that and just sort of take it as an opportunity to be like, hey, today you get to learn something cool. Know well actuallys, by which they mean that thing where people are like, yeah, so I was going down to the restaurant down the street, you know, the one that's yellow, and you're like, well, actually it's yellow-green.

Like, really? Like, do I care about that hair-splitting difference at this point? Again, if you have spent any time whatsoever in software, you have heard this happen all the time. And sometimes it's important to be that precise, but really most of the time you're just irritating people and you're making them feel stupid.

So, don't do it. No backseat driving. I don't know if that idiom works in Germany, but the idea basically that, you know, if someone is driving the car and then a passenger in the backseat is being like, no, you turn right, oh, no, do that thing, that thing, that thing. Like, they're trying to control the whole process, but they're not the one driving.

People do that with especially newbie programmers, too, right? They don't let them just sit down and sort of figure out, like, how to do the thing. Not even programmers. Like, any time new people are trying to learn a thing and experts are in the room, it's really tempting to tell them, like, everything, and you should really shut up, because you will just stress them out and not give them a chance to work through it

on their own and develop their own understanding. And then no subtle isms. So, things like sexism and racism and homophobia, like, it's really easy to end up there, maybe even through jokes that you didn't even necessarily realize were digging on people

from some background you may not share, but those are all really, they're effective ways to exclude people from your space. So, at Hacker School, they try to avoid that, and when they come up, you know, try to make sure that people understand, like, why that might be off-putting or insulting to people.

And then another well-known strategy for dealing with face-to-face events is conference codes of conduct, which are basically rules of the road. If you have a conference, are there things like sexual harassment

that you think people should not do there? If you think people should not do those things there, write it down, you know, have some rules, and then have a system for dealing with it, right? If there is something that happens at your conference that is not acceptable conduct in your space, to whom can people report those events?

What is that group empowered to do? You know, can they, you know, kick people out? Can they tell people to stop it, you know? But make sure you have it written down, both so everyone knows, and the process has some legitimacy, and also so that if, you know,

heaven forbid something does happen, you're not left trying to make it up as you go along. Because I've seen conferences in the past that did not have codes of conduct, and then some kind of big harassment event happened at the conference, and the conference organizers are trying to figure out how to deal with it at the same time as they are dealing with it.

And at the same time as all of Twitter is very unhappy with how they're dealing with it, and like if you want to just have nightmares as a conference organizer, like this is how you have nightmares. People never, ever deal with it well if they haven't thought of the process in advance,

because it's too stressful. So codes of conduct are rules that help you in an emergency and also help your attendees know that like someone will care if they complain about sexual harassment or something like that, because they may not realize that people will care, and so they may not feel comfortable looking for help.

But ideally, there are also dialogues that let you have a conversation with your community as to what do you value culturally, what do you think is sort of your aspirations for who you want to be. The best I've ever seen this done is Code for Lib. Which you can check out their GitHub.

Their code of conduct is on GitHub. People make poll requests. People have discussions in the issues queue. And it really provides a way for people to talk about like who do we want to be? Why do we want to have those values? How do we demonstrate that we are behaving in the way we want to behave? And how do we understand why things that may not seem relevant to us are

in fact important to some people in our community? How do we account for that? How do we understand each other? And then finally, in terms of governance, it's okay to have different rules for different spaces. In particular, projects that are large enough may have a sort of beginner friendly space

and an expert space that may have very different sort of cultures and expectations. And that's okay, because these people have different needs, right? Django has a Django users and a Django developers mailing list. And the users list is for people who may be completely new to the project. And they have very basic questions about like how do I do a thing?

And the developers list is for people who are, you know, writing Django itself and making major architectural decisions. And it's not okay to ask basic how do I do a thing questions on the dev list. And that's fine. It's fine to have different parts of your spaces, you know, your conference, your IRC channel, your mailing list or whatever, have someone different rules.

Just make sure they work for the people that you actually want to have in the space, which may not be the same as the people who are already in the space, right? There may be people who aren't there yet, because something about that space does not work well for them that you want to have included. So make sure to think about like what rules are actually correct,

which may be challenging, right, because it may require change. And that gets us into the idea of culture. If you have different rules for different spaces, if you have values that drive how you act, those are all questions of culture, like who are we and how do we want to treat each other?

The secret is everything is culture, whether your project is inclusive or not, whether your project makes wise decisions about governance or not, whether your project prioritizes things like writing documentation or not. This is all about culture. This is all about who you are as people and what your values are and what your habits are.

And I can't really tell you how culture works, so I'm not going to have sort of statements in this section, I'm going to have questions. One question, particularly for a semantic web crowd, is how do you organize knowledge? We do a lot of that here.

All schemes of knowledge organization will end up over-representing some points of view and under-representing others. And what that means is that some people can see themselves or their work reflected in your knowledge organization, and some people can't. So I'm going to give you an example from the Dewey Decimal System,

which I understand is not really used in Germany, but you can apply this to other knowledge representation systems you may be familiar with. So the basic idea of the Dewey System, if you don't know it, is everything has a number that is like a three-digit number and then maybe a decimal and additional numbers.

And so the 100s stand for one particular set of topics, and the 200s are another set of topics, and the 300s, and so on and so forth. And each of that is broken down hierarchically. So the 300s are about language and linguistics, and the first 20%, the 300s and the 310s,

I guess, of the Dewey Decimal System are about general topics and linguistics. So all of your general topics, they get about that much of the space. The next, I guess, 320s through 380s are European languages.

So that's great for many of us here who are native speakers of something like English or German or maybe French or Spanish. There are lots of places in the Dewey Decimal System that they can represent books about those languages. You can have extremely, you know, detailed numbers that really represent very fine distinctions between different aspects of those languages

because there's so much space in the categorization. And then literally the entire rest of the world gets the 390s. You know, Arabic, Japanese, Hindi, all of it has to get squished

into this time of classification. So it's just not possible to represent sort of distinctions among different elements of languages and linguistics. Okay. I thought I had a little longer than that. All right. So this is an example, but there are lots of others, which Wikimas just told me I need

to skip, but go read the Miriam Posner blog post that I link to. So like, I think I will have to skip this one, but this comes down to read the Miriam Posner blog post. Okay. How does your culture allow for peripheral participation?

There's this idea of legitimate peripheral participation, which is basically like people's participation in your community may not be that they're like core developers or conference organizers or something that's really hardcore. People's participation may be like they show up to one event or they make one like tiny little poll request to fix the grammar in your documentation.

How do you make that okay? Right? Because that's okay. Not everyone is going to be a huge contributor. And many people who will become huge contributors start out with little choices. So how do you make sure it's okay for people and easy for people to get involved in small ways?

How do you handle risk? When you have an open project, you're asking people to fail in public. You know, if people make a poll request on something like GitHub where everyone can see it, and they make a mistake, everyone can see it.

And that's really scary. How do you make it less scary? You know, if people make a mistake, are you like, wow, that was dumb. Or are you like, wow, yeah, I did that too. Like the first time I tried to do that thing, that's tricky. Let's see how we can fix it. My friend, Somanah Harishwa, she was at the Recurse Center at one point.

She was in one of their batches of programmers. And one of the things she said about that culture is I can't tell you how freeing it felt the first week to say I don't know a million times because I had been trained not to display ignorance for fear of being told I didn't belong.

That's ubiquitous in technology communities. And in both tech and libraries, we really value knowledge. So how do you make it okay for people to not know everything? And then the core question of culture is you walk into a space and you ask, you know, how might this look to someone else?

This is a gorgeous picture of exactly the sort of thing that I'm a complete sucker for. I can look at these sort of rhythmic architectural pattern photos for like ever and did while making these slides. But I could also look at this from a different angle and say this is completely inaccessible to people in wheelchairs, right?

This is hard to navigate if you have balance issues. Marble is slippery. There's a ton of steps. If you can walk but you tire quickly for some reason, you're not going to be able to deal with the staircase. Parents of small children may be looking at the separation between those rails and how far it is to the bottom and sort of quietly having panic attacks right now.

The space can be simultaneously just gorgeous but also off-putting or impossible, depending on who you are and what you bring to it. So the core question of how to make a community inclusive is when you look at a space,

including and especially a space that is really welcoming to you, is ask yourself, how might this look to someone else and why? And then if the answer you come up with is, wow, this looks like a space that I couldn't participate in under some set of constraints, you know,

what can you do about that, how can you fix it? In conclusion, you know, originally I was going to have like, I don't know, a thing about like the research about how diverse teams are smarter, which they are, and I was going to have some really like insightful thing

to wrap this all up in a bow. But then an awful lot of things happened over the past few weeks. My country had this election that none of us actually understand right now, which, you know, I'm looking at half the country hates the other half of the country and has no idea what they do all day and vice versa.

And suddenly inclusion seems pretty salient, you know. I'm sort of, I'm from the half of the country that voted for Trump and I live in the half of the country that would never dream of doing that. And so I'm sort of looking at people I value who think

that the other ones are completely evil. And I kind of wish they knew more about each other and maybe thought that we all live here together and should figure out how to do that without like being neo-fascists. So that happened and made inclusion seem really relevant.

But honestly I don't find myself having really smart things to say about that one either because in fact what happened with me over the last few weeks is I gave Adrienne and Joaquin a heart attack a few weeks ago because I emailed them and I said I might not be able to come to Germany. Actually I might not be able to finish my talk at all and we should prepare for that

because my daughter was in the hospital and she was so sick that, yeah, I didn't know it was really going to happen ever again actually. Anyway she's fine now, she's right here, yay. But I'm emailing the conference and I'm saying these things like I'm being a human being right now and that is more important to me

than getting any of my work done. Let's figure out how we deal with this, you know. Let's figure out what do we do if I can't come to Germany, can I deliver the talk remotely, how are the logistics for that going to work.

You guys should have a heads up of what if I can't do this at all, like you need to be able to prepare, let's make stuff happen. And they were great about it, thank you very much. If they had heart attacks they didn't actually tell me and we came up with alternatives for like how could I do stuff remotely. Because people are actually bringing a lot of their lives to your projects or your spaces

that you may not know about, like I didn't mention any of this on Twitter. And what choices can you make so that people can still be present and welcoming and get positive benefits out of being part of your community.

Even if things are going on in some way that make it really hard for them to do that. So what it really comes down to is that inclusion is about how are we human beings together and how do we recognize that in each other and how do we make conscious choices that make

that all possible for us to be humans together. Thank you.

Thank you very much. And from there, questions.

Thank you very much, that was absolutely fantastic and just what I needed to hear this morning. I have a question about how different levels of the community work together, particularly in the role of educating new members of the community.

Because I appreciated so much what you were saying about different levels of documentation and because I really value making communities open and accessible and providing inroads. And yet I also find sometimes that there is, and I hope I can articulate this well,

that there are issues where for any particular product or initiative there's too much emphasis on, well, we need to make it on, there's too much emphasis on we need documentation

for the newbies and not enough documentation for the higher level people. But also situations where I find that, man, members of the community who are not male and not white, et cetera, are the ones who get tasked with being the people who shepherd the newbies in.

And I love doing that, but I also know that not everyone who is like me loves doing that. And I hate it when other people are tasked with that. So I'm sorry, that's a long question, but I wonder whether you have any thoughts on that. Yeah, I mean I think I've got sort of three things in my head. One is that in terms of documentation, right, it sounds like you're describing the world

where people have written the tutorial but have not written the API reference or maybe the concept guide, and you need all three, right, you really do. Certainly the Django project is militant about requiring documentation for pull requests, and that can be part of your contributor guidelines.

It's like relevant documentation needs to get written before this can be accepted. In terms of the other stuff, there's a paper I saw somewhere, and sadly I cannot remember the site, which basically says that, you know, the people who are in the role of bringing new people into the community are basically always women

who are socially marginalized by the core contributors. So I've probably just described your life. You're welcome. That's a thing. I don't know how to fix that. It is really annoying. I share your woes there. I think, I mean I think a big part of it is if your culture claims to value bringing people

in, then part of what it has to do there is explicitly value that, right? It's like in US tenure requirements, you know, you have service as part of those requirements, like all right, like if that's going to be a thing you do, then recognize that that is a form of service, and that people who are doing that, it takes time,

and that is time that you should understand when you are looking at the rest of their contributions, right? Find ways to, yeah, explicitly recognize that. And yeah, in terms of the other thing, I think it's important for everyone in the community to know, and if people are not rowing this, like yell at them,

that just because like people are black does not mean they want to be on your diversity committee, right? It doesn't mean that they're necessarily experts in doing diversity outreach, and it definitely doesn't mean that they want to do it. Maybe they just want to write some code like everybody else, right? Actually, I staffed Lita's first ever diversity committee over the summer,

and I probably went through like 200 resumes because that outreach thing, it's high touch, but one of the things I was looking for is like not just are you maybe from some sort of community that's not well represented in Lita, but like do I see any evidence on your CV that you want to do this work, right? If you've not written about accessibility, if you've not been on a diversity committee

or what, like I'm not going to ask you to do it because that's not fair, right? You shouldn't have that extra burden. I don't know a way to solve this problem, but I think yelling about it a lot is pretty important because people may not realize that they're placing these expectations on people, and sometimes like, you know, you don't want to do that work just because you happen to be in a marginalized group.

Other questions? So thank you very much again. Thank you.