AlterConf London 2017: Open Open Source by Charlotte Spencer

(upbeat music) – Hello, can you hear me? – [Audience] Yep, yep. – Cool. So there are two things that you should do when you’re about to give a talk. Drink lots of caffeine,
not use the bathroom, and eat food. I’ve done none of those things, so I’m really excited to get going. (audience laughs) Hi, I am Charlotte, I’m charlotteis, if you want to tweet about me, feel free, but my pronouns are they and them, I am super queer, super
trans, I’m very loud about it. If you’re wondering about the cane, I got this through
smashing the patriarchy. (audience laughs) I’m a developer at uSwitch,
been there for a few months, really cool, really good
stuff, I think we’re hiring, blah blah blah, but I
don’t care about that. I am a core contributor to Hoodie, which is an Offline First
javascript framework, which tries to make people who
aren’t so good at front-end have an easier time
building their first app. And I am an admin on wealljs, which is what I like to think as an inclusive Slack
community, where people, such as minorities and such should have the space
to learn, in a nice way. All of these things involve open source, so I should probably define
what that is before I go on. Open source is software that
can be freely used, changed and shared in modified or
unmodified form, by anyone. Which is a great definition,
I fundamentally disagree with. Because I do not believe that open source is accessible to everyone. A lot of people who
contribute to open source tend to be cis white men who have the time, energy
and internet connection, whether fast or, even on a
2G in the middle of nowhere, can still get them on somehow. Little experience of harassment and employment. So it’s quite hard to spend the time contributing to open source when you’re desperately looking for a job. It’s quite a negative view of open source, but I’m here to tell you
that we can make it better. So I’m gonna outline five
things that I could do with our open source projects to make them more
accessible and inclusive. I’m probably preaching to the choir here because a lot of these
people do these things. I’m gonna do an eight minute
diatribe on codes of conduct and you’ve already all signed
one, you know what they are. But it’s always good to outline
why they’re good to have. So codes of conduct, which I think is the most important document that you’ll have in your project. Code of conduct is, for example, a document that’ll sit
in your GitHub repository that outlines what is and isn’t acceptable behavior within your project. It hasn’t happened in 2017
that I’m aware of yet, but we’re still early days,
but there was a lot of furor over codes of conduct in 2016,
a lot of well known projects that I won’t name, said, “Well,
what about my free speech?” This is code, I should be
able to do what I want, and say what I want. That’s a much longer talk, which I don’t really have the energy, or the care to talk about. (audience laughs) The TLDR is, if your free speech is actively harming
somebody in my project, you can get the hell out. Code of conduct isn’t a catch all though, so if I have a code of
conduct, it doesn’t mean that, “Oh wow everyone’s going to be “really nice and lovely to each other, “what a great time I’m having,
in this open source project.” Rather it’s a pledge
by project maintainers to the best to ensure the
safety of their contributors and their fellow maintainers. My favorite code of conduct
for GitHub repositories and other open source
project is weallcontribute. I’m a little bit biased, because I did help
actually create this one. It’s just been released as a node package, which will be continuously updated, so you can have some help with creating your code of conduct. And for events and stuff, I
like Conf code of conduct. It needs a little bit of
work, but it’s a good starter if you’ve never had a
code of conduct before for your events. So, get a code of conduct,
really, get a code of conduct, it’s 2017, you should have one. But, make sure that you read it first, because there’s no point
in having a document that you don’t actually
know what it contains. And a lot of people don’t
read their code of conduct. They copy and paste and
attribute a bug number, weallcontribute conf code form that say I’ve done the needful now, now people, buy tickets to my event. It’s not how it works. Make sure to keep it updated as well, there are a lot of people who
do that copy and paste job, they understand what
they’re signing up to, but they’ll let it sit
there for three years. And if you’re using a code of conduct that is an open source
project, that code of conduct is being continuously updated. So you should treat it as you
would treat a node module. You look at your node modules
to worry about security issues you should be looking at your
code of conduct to make sure that it is protecting the
largest amount of people that you can. If you’re gonna have a code of conduct you should be prepared to deal
with problematic behavior. It’s worse to have a code
of conduct that you’re not going to enforce than not
having a code of conduct at all. I’d rather know where the
project stands without having one than be lulled into a
false sense of security, something bad happens and
then the maintainers go, “Well maybe you could be a bit nicer.” (sighs) Doesn’t work like that. Reason why I like wealljs’
code of conduct so much is that it has really
large and robust section on enforcement policies. And there are just three key points that I like about our enforcement policy that I wanted to talk about here. First of all, are, “What
about my free speech”, and “I hate code of conduct” people. We all mess up. Everything that happens
can be treated differently, it’s a case by case scenario. If you say one bad
thing, I’m not gonna say, “Well you’re not allowed to
do any code forever now.” I’m gonna take that, and
we’re going to work together to solve the issue. Safety of the hurt takes priority. If you’ve come to me with a complaint, then I’m going to do it with you, because you’re more important than the person whose done the harm. And lastly, we promise
support, not safety. If you come into my
project, I can’t guarantee that everyone’s going to be really good. Something will happen. And that’s what I want to get across to people who do events today,
something will always happen. I can guarantee something has happened at every single event that you’ve been to. You just don’t know about it. I will do my best to protect you, but I can’t guarantee that
nothing’s gonna happen. When I wrote this talk,
it was about a year ago, and there was this
person called Ashe Dryden who I thought was really cool. (audience laughs) And had this really good 101 and faq. So, Ashe did some really good
writing on code of conducts, so if I haven’t convinced you,
they have a much longer piece where they talk about
what a code of conduct is, why a code of conduct exists,
how to enforce it, etc. It’s a really good piece, so,
please do have a look at it. The second most important document in your project is the readme. This is the first thing that you see when you go to someone’s project. And it might be something like this. Welcome to unicorn.js. I’m of the unicorn riding sealitour. To use it install node,
make sure that you have npm. Install unicorn, and
then ride the unicorn. (audience laughs) This is a good primer for a basic project that you don’t really
want anybody to touch. (audience laughs) But there is so much more
that we can provide to people. I say that this is to help other people, but it’s also to help you,
because the less issues that you have to deal
with, the more likely you’re actually gonna like
working on your project. So, title of the project,
“Welcome to unicorn.js. “Home of the unicorn riding tool. “Here’s our code of conduct, “anything that you do with unicorn.js “is subject to our code of conduct “and we expect you to
behave appropriately. “To install it, make
sure that you have node, “make sure that you have npm,
and then npm install unicorn, “ride the unicorn. “But if you wanna go more, “here are some books,
tutorials, videos, etc, “to get more experience with unicorn.js. “You’re gonna get stuck,
so when you get stuck “check us out on Slack, IRC, Gitter, “whatever weird communication
tool that you’re using. “Or you can log a GitHub issue. “Here’s how you file a GitHub issue, “please stick to the template,
because that will help us “triage your issue much quicker “and it will give everybody a nicer time. “Security issues completely
different though, “so if you could email us
at [email protected] “that’d be really appreciated. “We’re an open source project,
so we really need your help, “and 2.0 unicorn.js is shipping
an all-terrain unicorn. “Here are some issues
that you can help me with “so we can get that shipped. “And lastly, if none
of this applies to you, “or you have a different question, “or you’re just a little bit shy, “then email me, at [email protected] “And then we can have
a good time together.” I briefly mentioned GitHub issues there so I wanna touch upon
that a little bit more. I’m lead creator of Your First PR, which longtime followers will
know that is pretty much dead, because I’ve resourced it. But when it was alive, it
was tweeting GitHub issues that I believed to be approachable for beginners to programming,
beginners to open source, or someone who was just
looking for something to hack on a Friday that
didn’t take too much effort. ‘Cause I believe that open
source is a great place to learn. Despite my world-renowned expertise I’ve only been programming
for about 2 1/2 years, entirely self-taught. And one of the first things I did was look on GitHub for
things I could contribute to. I ended up finding this
little project called Hoodie. And none of them had
English as a first language. So they had some grammatical problems. So I helped them out with that. And then, six months later
I was a core contributor, shaping the community and making sure that it was open to beginners. If you know Hoodie, you know that we have a lot of issues for beginners, we actively take in new
contributors by handparing issues that we think that they could fix. This is the first issue
that we created, it was me, I’m the best. (audience laughs) January 2016, which was a long time ago. The Hoodie website had,
and still does have, accessibility problems, just
too much for me to tackle, with an open source project. So I thought I’d open
it up to other people, so they could learn how
to do accessibility. Because if there’s one that’s
true of a lot of developers, it’s that they have no
idea what that means. So I explained the issue. I give the solution, rather
than the problem in the title. So you already know what you’re looking at without having to click in the issue. So, give the hoodie logo
meaningful alternative text. In the bug report itself I
explain how you can replicate the issue, and then we give
step by step instructions on how you’re going to fix it. From forking a repository, to the commit message that you should use, if you get stuck then feel
free to reach out to me on Slack for example. Labels are your friends too, they’re not just there to look at. I used bright red bug
label, which is convention across GitHub and even if they
turn out to be a big mess, bugs are usually easier,
or more approachable for beginners to fix, rather
than a fully fledged feature. So you can come help me fix
my accessibility issues, you might not be ready to ship that ultra-ray unicorn with me. Help wanted, it’s always
good to be explicit. A lot of people can pop up
into GitHub issues saying “Here’s your solution,
I fixed it for you.” And it’s like, well actually I
was really looking for a fix, I was going to do it on my own. So help wanted label really explicitly tells people that you’re
actually seeking help. And then lastly, starter issue, we don’t use this label anymore in Hoodie, but I use it across my other projects. This is to say, “Hey, if this is your first
experience of this project, “here’s a really good way to get started “without touching too
much of the code base.” And also assume that you might be mentored on this issue as well. So that’s GitHub issues,
but before we even start writing our readmes and
our code of conducts and our GitHub issues, we have to think about the language that we use. You are reaching an audience
of many, many different people from many different walks of life, and we need to make sure
that we reach all of those. First up, everything that you write should be clearly worded, just
because we know fancy words doesn’t mean that we have to use them. The Government Digital Service,
thank you to our sponsors (audience laughs) recommends writing for
a reading age of about nine years old. I might be really good at code but I might not be able to understand the things that you’re writing. So write it simply. There are tools that can help you as well like Hemingway App, which I rely on to write everything that I do. Yeah, keep things simple. Now we’ve got our favorite
topic, if you know me. Gendered language. So, I’ve already mentioned
that tech is dominated by men. So you’ll see a lot of
programming examples that don’t need this but they also assume that the person that they’re
explaining to or talking about is a man. So they’ll use he and him. That’s not very accessible. So a couple of years ago
people started to do like, “Woow, let’s use she and
her, because women exist too” And if I’m not mistaken,
that’s kind of appropriate. Thank you for the shrug there,
women do, apparently, exist. (audience laughs) And I’m not saying this just
because these are my pronouns, but they and them is a really
good way to speak to someone without assuming anything about them. Similarly, don’t ever
talk to me in a group and say “hey guys”. I will say, “not a guy.” (audience laughs) And I do this every day at work. You may think that hey
guys is gender neutral I respect your opinion, but I also respect my
ability to disagree with it. Half the room might agree with
this, half the room might not so why don’t we try and be
a little bit more inclusive of people who don’t like hey guys. So, no to that. Suggest, hey everyone! Hi everybody. (audience say hello) See, you all respond, it’s that easy. (audience laughs) But language is quite hard, so we can use computers to help us. In Hoodie Slack, every time
someone says “hey guys” (audience laughs) this is usually the first thing My communist mind. (audience laughs) Usually, whenever a new
contributor joins Hoodie, and it’s quite a 50-50
split in terms of gender if you believe in that
weird gender binary thing. And they’ll say, “Hey guys,
I really liked your project.” And the first thing that they’ll get is, dd you mean comrades, or
did you mean everybody, or something similar like that? And nine times out of 10 they
go, “oh I’m really sorry,” edit the message, then we
continue the conversation as if nothing happened. It’s nice to get slackbot
to do this, because people don’t really like being told
off by real human beings. (audience laughs) Just to touch upon ableist
language a little bit, in wealljs, we have semi-automatic
slackbot responders. So, if I come in and I say,
“Ah, that’s really crazy, “this javascript framework is so crazy.” Then I could be like, well
firstly, a javascript project isn’t an entity, it’s a thing. But words like insane and
crazy are terrible descriptors. I have a variety of mental health issues and I don’t appreciate
it when someone says that a javascript framework is crazy. So I explained that it’s
not a good description, and how about shocking, or amazing, or ridiculous, or wonderful? There are so many better descriptors and it makes you a better writer as well. Haven’t really spoken
about code in this talk because I believe that in open source, code isn’t particularly important. I can write my unicorn module tomorrow. But no one’s going to see
it, without people writing the newsletters, without
people doing design. And I’m not talking
about needing a designer to do some logos or something,
because to reduce design work to that is fundamentally wrong. Community moderation, who’s managing our Slack channels or our Gitter? Who’s writing our documentation, because apparently developers
don’t like that very much. I think it is my favorite thing to do. Yeah, so all of these
things are really important. And people often ignore these things. But actually this is the core
of your open source project. And something that we should
pay more attention to. We have an editorial team at Hoodie. I’d consider doing something editorial if you’re open source
projects quite large. Get some people, a
dedicated repository people, to actually start looking
through these things. Because you attract a really big audience. I’m a programmer, but I actually don’t do a lot of open source code. I spend more time writing
things, and moderating things, and documenting things,
because that’s what I enjoy. So a lot of people who
don’t like writing code outside of the office but
will really like doing those sort of things. I’m gonna finish now. I’m a little bit over
time, under time rather. But I wanted to point out my last section. Which is that you are important. Burn out is real. I’ve done it twice, but I feel like I’m
doing it every weekend. And without you, there is no open source. So if you need to take naps, if you need to go eat a giant
pizza to yourself and cry, do that, because the open source project will still be there when you get back. Because at the end of the day, this is my vision of open source. A variety of cute, soft animals,
in hoodies, by a camp fire, discussing how much they enjoyed doing their first forward
press, how much they enjoyed interacting with the
open source community. Thank you, I am so honored
to speak at this conference. It might be my last although every person
I say this to has said, “Charlotte, you said it was
your last six months ago, “and here you are.” This is the most diverse group
that I’ve ever spoken to, which is a shame, because it
should be like this every day. And I’ve also never been signed,
I’ve never been captioned and I just think that the work that Ashe and everybody else
here has done is phenomenal. So that you so much for coming. (audience applause)

Leave a Reply

Your email address will not be published. Required fields are marked *