 So I'm going to talk about finding a great project to work on or finding great people to work on your project. I've been talking to code projects about how to find non-coders to work on their project for a little while, and so Tim asked me if I could flip it around and help folks who don't code find a great project to work on. And as it turns out, what happens when I talk to folks about how to find non-coders for your code project is that code projects end up with lots of ideas, but then non-coders were like, oh now I know like how I can ask for the things that I need from projects that I want to be involved with. So they're already like kind of two sides of the same coin. And my colleague Shana finds out the same thing like when she has she's done some talks also on how to find a great project to work on and then someone will raise their hand from her project and be like, our project doesn't do that. Does that mean we're bad? And she's like, well why don't you do that? So hopefully you'll be able to follow whether you're, I don't know how many people are looking for a great project to work on. Yeah? Okay, some hands. And then how many people have a project that they want great people to work on? Okay, more hands. So, you know, and maybe sometimes you wear both hats, right? So the first rule for when you are looking for a great project to work on, and this is my colleague Shana that I mentioned, is do not put up with any crap. We all know that there are some projects that are curmudgeonly, and there are plenty that are not. So if you find one of the curmudgeonly ones, just move on, right? And so the flip to that, of course, is if you're running the project, this is Aretha Franklin, people know who she is, right? Ariya, she's C.T.? Okay, great. So the flip to that is if you're the project and you want great people, then you need to treat them with respect. It feels like you shouldn't have to say that, but apparently, I find projects that don't do it all the time, and we'll get into the details of how that works. A little bit. Another way of finding a great project to work on is to figure out if their current contributors are happy. So, you know, and every project has, it's little ups and downs and things that they complain about, but if you get the sense that people are like, I'm super happy to be part of this team, I don't miss the teeth anymore, it's fine. So if the current contributors are happy, then it means that the project is treating them well, and it might be a good place for you to spend your energies. For project leaders, that means that if your current projects folks are totally unhappy, then you should find out why. And people are always like, oh, well, how could we possibly find out why people are unhappy at our projects? And they come up with like a million ideas of how to figure this out, except for actually asking them, which is by far the most effective way to find out why your current contributors are unhappy. Another thing that I think makes a project really great is if they are teaching people to fish. Have you seen, we had this in my first grade class, it was like, if you give a man a fish, he eats for a day, and if you teach a man to fish, he eats for a lifetime, right? Okay, so this is kind of the same thing. If you teach someone how to do a bug report, then they can file all the bugs. But if you're like, just tell me what's wrong and I'll file it for you, you see how that works. The teaching someone how to do the bug report and explaining why we do it this way is going to produce someone who feels like, yeah, I could go and file more bugs. Awesome. So you want to look for projects that are teaching people to fish. And that means if you're running the project, like doing the best you can to empower people to kind of follow their desire to do a bunch of free work for you, un-cumbered by you. Get out of their way is what I'm saying. Another thing that I think is really critical is that code isn't everything. Obviously code is important, but it's not everything. So when you see a project that has contributed with a lot of different skills, you tend to see folks at conferences, folks that are willing to wear a Fox costume, cupcakes with tiny 3D printed ganous on top of them, like all of these things that make it super, super fun, right? And everyone is doing the thing that they're good at. I'm not saying that coders can't bake cupcakes. Some of them probably can. Some of them maybe can't. For projects that think, you know, sometimes you have this creep, apparently it happens with lawyers too. I work often at the intersection of coders and lawyers. They're like, well, I'm really smart. Like there's no way that I couldn't just figure out how to do that. And so when that happens, you end up with this, right? Are people familiar with the lady who kind of jumped in to fix the Jesus painting? Yeah. And I've seen this where it's like, oh, graphic design. I could just jump in on that and done by coders or lawyers, and it's not pretty. Especially they're like, oh, it shouldn't only take me an hour to learn this, right? Yeah. So once you've found a couple of projects that you think like the current contributor is seen happy, and they want non-coders or people with your skill set, whatever it is, then start up a conversation as soon as possible. The difference between waiting. So when you do this in code, it's really bad. You check out the repo. You look at all the bugs. You pick out a bug. You patch it. And then you spend hours and hours and hours. And then what if it's not in the right format? It's not documented correctly. Someone else fixed it last week and you were in the wrong branch, whatever. But if you're doing, so the earlier you start talking to people, the better a sense you get of where your contribution fits in. You get more guidance. They get to know you. You get to know them. So the earlier you can start the conversation, the better. And it just makes it better. Because if you've gone for several hours of doing like unrequested work and then you find out that it wasn't needed, it's really frustrating for you. But then it can also be really frustrating for the project person because they're like, oh, man, I so wish you'd talked to me. You really screwed that one up and spent many hours on it. So the conversation should start early. And that should hopefully be the easy part, right? But not always. So projects have like this info email or like one that they gave up long ago because it's filled with spam or something else. And so no one answers it. If you've got one of those on your project website, like get rid of it. I think when you're looking for projects, what you want to see when you contact the info list or you come into the IRC channel and you're like, hey, is anyone around? I just downloaded your software or whatever. Is a response as soon as possible. And if you can't do a response as soon as possible, then you should have an auto responder that says like, hey, we're a volunteer project. We're super glad that you wrote to us. It typically takes us three to five days to get back to folks. And so don't worry, we're going to get back to you. So if you can't get back to people right away because you just don't have the number of people, let them know. And that kind of rolls into this. Like a good website for your project should function as a welcome wagon. It should be really friendly. It should be really nice. It should be really obvious. Like we want new people. It should say what your project actually does, not just like a link to the repository or I saw this a couple of years ago where it was twisted. It's like, what is twisted? And you click on it and then it's a list of like 20 sub projects have twisted, which all have weird names like cyclone harvester or whatever. And it never really said what twisted was. And so, you know, and then the kind of like went backwards and like, well, we pretty much figure anyone who wants it already knows what it is. And I'm like, so how do you get new people? And it's like, huh, we don't like I can see why. So healthy project will be happy to greet new people. So like I said, like setting expectations about how long it'll take you to get back to people on the email, letting them know like, we're really happy that you're here. And, you know, it'll take us, you know, we have as many people. And kind of you can one trick for letting someone know that you're really happy that they're there, but without spending a lot of time on your first contact, is to ask them a question or two. So someone's like, hey, I'm really excited. I find your project. And you can say like, great, awesome. How'd you find us? Or what are you interested in? And then you got to you bought yourself a couple of days on that first contact. And they're like, oh, you want to know about me. That's fantastic. So you should be looking for these things when you want to find a project that that is going to be excited to have you working with them. Obviously find something interesting to you. Because non coders and coders, like we were kind of the thing. But we're also, you know, like, all of these things, like we need food, we need shelter, but we also want to be liked, we want to learn stuff. But we're also a little different. Like, we, we don't necessarily look at stuff the same way. Like, something like, something that's exciting to a person who's working on the code part of a project is like, ooh, we're using this cool new SQL database that no one's heard of. It might not be so exciting for people who are working on your blog. Because they don't actually care about that. But if you were able to say like, well, it's a new SQL database, but it also connects doctors and patients and helps make the whole process of sharing healthcare information more, you know, more efficient. And it's like, oh, so no SQL, whatever, saving lives, that's cool. Like, unless you're, you know, the person who's going to be working directly with the no SQL database, right? So, not to, I don't mean to knock no SQL. So, it's nothing wrong with it. So, kind of going to like, how other folks have found great projects. I think 101 is you said, you should look for a code of conduct. That means that the project has given at least like, this much thought to, what will new people be treated like when they come to our project? And what kind of people do we want to have here? Do we want people who are like, oh, sweet, I was looking for another place to bully people online. Like, hmm, maybe not the project. But the code of conduct says like, oh, we're actually are not trying to bring those people in. And so, you know, as a default. So code of conduct is a really good first sign. Another thing that is great is projects that have participated in outreach programs. Do people know about the GNOME outreach program for women? Yep, a couple. Okay. It's actually going to be not as only women soon. They're going to be having parts for women and other folks that don't traditionally participate in the creation of software. So they do this paid thing, which means whether you can participate in this or not, all of the projects that have done this kind of a thing are interested in having a pipeline for getting people from, I don't know who you are, to I'm contributing and I'm really happy to be here. So if projects have already participated in some type of an outreach program, then you know that they have a pipeline for new people. So that means if, you know, as a potential new person yourself, they're not going to be like, uh, you're staying over. I don't know where the bed is. I'm sorry. Is the porch okay? You know, that kind of thing. You want a project that's kind of ready for you. OVW is also really fantastic about having non-coders. So that one is really specific if your skill set or the way that you want to contribute currently isn't code. So they do a lot of onboarding, non-coding volunteers. And this was put together by my friend Molly. I'm sure folks have heard of the Google Summer Code. All of the mentoring projects here, again, they have a pipeline for new people for bringing new folks in, getting them up to speed, getting them to be productive and be happy and, you know, fulfilled with the process and all that type of thing. So any project that's contributed to Google Summer Code, you know that they've at least tried to set up this pipeline type of thing. Uh, Open Hatch. I'm on the board, so I'm biased, but I think we do a pretty great job. Two resources at Open Hatch. The mean page, which is the first link, has a link to bite-sized bugs. And those are mostly code things, but we also on the wiki have recommended projects, like projects that we know do a good job of bringing in new people and getting them up to speed and getting them happily contributing. I'm not sure right now we edit that ourselves, but we may open that up to folks with some caveats to add more projects there. So that's a really great place to look and it might be growing soon. Another thing that I think is really great, if you're going to be doing non-coding work, is to be looking for projects that post about their non-coders. So lots of code projects will be like, we have a new release, we added this and, you know, this, that and the other thing, like you can script adding more media or whatever. And if you, if a project is really excited about their non-coders, then they'll also blog about them. And that way you know that they're like, yeah, they're not like code and all the other things. Because if you're going to be doing all the other things, like why do you want to be at the bottom? So another project that I am involved with, Media Goblin, we always make sure that we thank all of our contributors, whether it's code or not, whether it's, you know, anything. We had someone, our mascot wears a purple beret. And so we had someone who was like, I'll help you find purple berets for your team members. We're like, awesome. So like next release notes was like, thanks to Morgan, who helped us find purple berets for all our team members. You know, so that, we do that conscientiously because we want to signal to the world that we think that all of the, you know, all of the participation is awesome, not just the code and then the other things. So, so looking for the way their projects talk about their non-coders is going to find that. So for you're not blogging about your non-coders already, you should be. Another place, internships with your, maybe it's less of a huge commitment than the three months, $5,500 stipend that you have with Google Summer Code or the outreach program for women. But this is another like, hey, we do kind of want new people at least. So if projects have internship postings, then you know they have at least some idea of what it's like to onboard new people. So again, those are, that's another great way to find folks. And internships are fantastic. You know, it's, you get folks that like school, right? Do people know what, this is, because it's copyrighted, but this is that school. But yeah, so internships are another way to signal to the world like, we like new people, we like onboarding them, we like hearing about what our project looks like from people that haven't been here contributing with us for like six years or more. So those are, so an internship is fantastic. One note, it is not get a person to do your dry cleaning and empty the trash and mop the office. Like, and in some places, I don't know what the deal is here in New Zealand, but in some parts of the US it's illegal to do that beat and switch where you ask interns to come in and do some learning stuff and then they do a lot of janitorial stuff. So, so if you're a project and you're like, we could use interns and you started thinking about having people pick up your lunch and drop off your dry cleaning, like just nip that in the bud, not okay. And then finally friends are friends. So if you have friends that are working on projects that they're really excited about, ask them if they need more people at that project or if they have other ideas for other projects. And it's the same for when you're looking for people for your project. So if you're like, yeah, that other project always has so many awesome people working on their graphic design, like again, you could do a whole game in your head of how to find out how they did that or you could ask them. Since we're doing free software, we're like kind of all in the same team. So I bet they would help you out. And again, just because if you do find, if you will go through all these things and you still find a project where people are mean to you, leave, because you can come and work on another project. You can work on one of the projects that I mentioned. And I will, I would be happy to be your friend of a friend and have you come work on Media Goblin or have you come work on Open Hatch, or if you like legal issues, come work at the Open Invention Network. So thanks so much. And I have time for maybe one question. Yeah, I have a question. You mentioned about code of conduct. Yeah. Policies. Are there any ones that are available like templates or that? Yeah, absolutely. I've never seen any. The Geek Feminism Wiki has templates for codes of conduct. Okay. Other projects that have really great ones, the Python Software Foundation, Ubuntu, and KDE. And they're all under Creative Commons license. So you can cut and mix any of those. Okay, cool. Thanks. Oh, yeah. That's a local one that I didn't know about. Linux, that's right. Anything else? Are you guys ready to go find a new project? Or find new people? Yes. Okay, great. Thanks so much.