Building communities for junior contributors

Transcript

My name is Conrad Hollomon and I volunteer with an organization called Operation Code. And we're going to be talking about how you make it so, with your community that you run, you can make it as easy as possible and as fast as possible for somebody who might be coming from a lower level of experience, somebody who might be a little bit more uncomfortable doing open source contributions, how can you get them to be a part of your community and to be working together with others as quickly as you can.

So a little bit about Operation Code. We are 501(c)(3) non-profit and we are working with military veterans, transitioning service members, and military spouses to help them learn software development, enter the tech industry, and code the future. In the background here, you have a chapter in New York City. We have various chapters throughout the country.

And this is a community that is very much an underserved community. About 250,000 veterans transition from the service a year and need work. The military spouse community actually has an unemployment rate four times the national average and this is a major, major problem for anybody who's ever served or anybody who's in the family of somebody who served.

And what we found is that, as we've explored this community and as we worked more with this community, what we found is that that sense of service and that sense to want to contribute to something more than yourself actually has a very, very powerful alignment with open source.

Mission-focused alignment

It has a very, very powerful mission-focused alignment in terms of a bunch of people coming together to try to accomplish something that's greater than themselves.

A little bit of background on myself. I was a former U.S. Army captain. And we all kind of got together to help build this organization remotely actually. We all got together on Slack, Portland, Denver, Boston, we all encountered each other.

We were all kind of doing stuff in our local communities to try to help and then we found each other online and it was like, why don't we just like try to do this all online? Because we kind of started as a remote-first organization organically and then it just grew from there.

This community is for you

So the number one thing that we want to make clear for somebody who joins our community, and our community is primarily on Slack, we have a web front end that gets people onto Slack as quickly as possible that's a whole other like little onboarding challenge, is sending the message that this community is for you.

This community is for you, you personally, you, John, you, Sarah, you, Eric. This community is for you and we are here to make sure that you feel welcome here as quickly as possible.

We actually have a bot where we've gamified a little bit our community volunteers greeting somebody as fast as possible. They will compete with each other to try to greet people via DM or publicly as quickly as possible, asking them, "Hey, what would you like to learn? Where do you want to go today?" I didn't mean to quote the Microsoft like thing there. That that was a little bit spontaneous.

But like, "What is it that you would like to learn? What would you like to build? What would you like to create? What would you like to contribute? Where are you on your journey?"

Some folks who come into our community have never touched coding but they've installed the Slack app for the first time. They're on a base, they're on their mobile phone and they're just like, "Okay, so I want to learn about this stuff. I'm getting ready to leave the service in, you know, a few months, so I want to learn a little bit more about this."

It ranges all the way from that to folks who, you know, have just graduated a coding boot camp or evaluating coding boot camps all the way to senior engineers who may be veterans or military spouses.

A little known fact is that a lot of veterans or military spouses will not identify themselves that way at work. And the reason for that is that they are afraid of how they will be perceived at their job, either because they have come from a deployment or because they are reservists where they may get called up, or because they're military spouses where if their husband or wife gets stationed somewhere else, all of a sudden that company needs to find a new rec.

Regardless of where you're coming from

So very often you will not even know that the person who you're working with is a military veteran or a military spouse. And we really want to send the message that like regardless of where you're coming from, this community is for you.

And when I say regardless of where you're coming from, we are not checking, we are not looking to see. Hey, we ask if somebody is a veteran, we ask if somebody is a military spouse. But we have just as many civilian volunteers who want to give back, we have just as many folks who are recruiters, we have folks who are senior engineers who just want to give back or they just want to interact and maybe share war stories or talk about that kind of thing.

Software development is a team effort

One of the things we really want to emphasize with anybody who's coming in and learning for the first time especially if they're finding out if coding is right for them, once again, is that software development is a team effort. It is a team sport and we want to get our community involved as a team as quickly as possible.

That means seeing that there are folks to your left and right that are going to help mentor you, they're going to help guide you through this process, that are going to give to you and help you through this.

RTFM is banned

The acronym RTFM is banned, all right? We do not use that acronym in this community, all right? Actually correction, sometimes the manuals can be friendly so I encourage people to read the friendly manual but we don't want to emphasize this idea like, we want to emphasize self-reliance but the community that we're working with already has developed a certain sense of self-reliance. This is about helping them make their transition.

And believe it or not, this has been one of our most powerful tools to do that. I know what you're thinking. Like when you think of something friendly, easy to onboard, great user experience, the first thing you think of is Git, right? That's exactly what you think of. Bear with me for a second because the most powerful thing about Git is its ability to allow a lot of people to contribute to one thing.

And when you tap into that and when you show people that they can do a pull request, when you walk them through that process, even if it's something as simple as changing a string or changing a color or something very rudimentary and very basic, the act of having a senior engineer or somebody on the team look at it, provide a little bit of constructive feedback, and say yes...

When you onboard very, very quickly, it's probably one of the most powerful things you can do to show that like, "Hey, this is actually a place where they're going to be supportive and they actually are interested in what I have to contribute and what I have to give back."

Give new contributors an early win

So give new contributors an early win. You not necessarily need to have an early contributor contribute some major feature and that's the only thing they can do. Give them something quickly that they can use to show that like, "Hey, I have contributed to something greater than myself." Get that happening as quickly as possible.

The same way that when you're working on a website and you're trying to like, the same mentality and the same mindset that you have when you're trying to acquire users really quickly, when you're trying to get their email addresses, give your contributors that.

Get to 'yes' as fast as you can

Think of it from their perspective too. They're motivated by what they can build. Let them do that. Let them build something and contribute to a larger whole as quickly as you can. I can't stress that enough. I even have a slide for it, right?

Now I'm not saying that you should compromise on quality. What I am saying is you should offer opportunities where you can afford to accept a little bit more risk because the scope of the change is so small that it's not really going to necessarily affect the grand scheme of what you're working on in terms of the project.

Setting people up for success

That means setting people up for success. That means you need to do the diligence on your side in terms of what you build and what you make and what you create in terms of documentation, in terms of onboarding, that entire experience to make sure that they have all the information they need to be successful in the community.

Because if folks are coming into your community and then they're leaving and they don't feel like they've been provided that information, let's be real, whose responsibility is that? Right?

Who are the ones who can set new developers up for success the most? Who are the folks who can set up new contributors to be able to be productive the most? Who is responsible for that? Open question.

Contributions are more than just code

Contributions are more than just code. Contributions are more than just code. Contributions are more than just code. If you look at contributions and you only reward folks who submit pull requests and make code, you'll end up with a lot of code.

How many people think just a lot of code is a great thing in and of itself intrinsically? I know it can certainly feel that way. It can certainly feel like you're being very, very productive when you move really quickly and try to hit up every single one of these things.

But let me tell you what I'm looking for the most. I'm looking for the folks who are willing to write documentation. I'm looking for the folks who want to write tests. Please give me more people who want to write tests. That is amazing. Those folks are Godsent. All right?

And the more that you want to contribute to the success of the entire thing, you got to look at more than just code. You've got to look at going out into the community and writing these blog posts, you know, providing like constructive tweeting, all right? There's lots of examples of different kinds of tweeting and we're focusing on constructive contributions to the community. Contributions are more than just code.

Many contributors make a community

And alongside that, it takes a lot of different contributors to make a community. When you're looking at the folks who enter your community, every single one of them has a gift, every single one of them has a superpower. It is the role of the folks who are managing that community to find out what that superpower is.

Some of them, it might be building features. Some of them might be writing tests. Some of them, it might be onboarding people themselves. There are a lot of ways to contribute to a community but it takes everybody to make it happen. And you want to think of this.

We talk about diversity, we talk about inclusion, also, think about this in terms of the kinds of people that you are communicating you want to bring in. Are you only wanting to bring in Ninja rock star engineers with, you know, 20 years of experience and Windows 95? I don't know.

You've heard the cliche about resumes and asking for more years of experience than the technology has even existed. Is that what you're looking for?

Or are you being just as welcoming to people who want to be effective communicators? Are you welcoming project managers? Are you welcoming to product managers? Are you welcoming to marketing people who just love technology but they want to find a way to communicate that message?

Who is a contributor?

How are you enabling them to be a part of your community? How are you bringing them in? I want to clarify what I mean by a contributor here, all right? If you do any of these things, you are a contributor.

If you're an advocate, you're a contributor. If you answer questions, if you know, like to write nice notes for people who submit pull requests for you, you are a contributor. God, if you create documentation, I'm not going to say you're more of a contributor but I'm just saying like I'm mentally thinking it. All right?

If you ask good and constructive questions, you're a contributor. If you're providing good feedback, you're a contributor. If you are blogging about your experiences in the community, the good and the bad and doing it in a constructive way, if you are helping people work with each other and connect with each other and grow, you are a contributor. You are an open source contributor, all right?

If you interact with others in a meaningful positive way

Bottom line. If you interact with others in a meaningful, positive way to help everything move forward and help the community move forward, you are a contributor.

And I want to challenge each of you to like try to represent that and try to send that message within your own organizations and within your own communities that that meaningful and positive interaction whether that be through coding, whether that be through tweeting, I guess that's a couple of different ends of the spectrum there, but like if you interact with others in a meaningful positive way and help them become more effective, you are a contributor.