Welcoming contributors to their new neighborhood

Recently my wife and I made the move from my native Indiana to the warmer climes of North Carolina. There is a lot of work involved in packing up all of your material possessions and moving 730 miles. Then, once you are finally at the new place, there is a lot of work re-settling to make that house a home.

Beyond the inevitable foibles of unpacking, and wondering why you needed to bring that umpteenth coffee mug you got at SCaLE 9x, another big adjustment comes from re-establishing your bearings in a new community. Everything must be rediscovered, where’s the grocery store? The gas station? Where is the best takeout pizza (an imperative in the Proffitt household)? 

It doesn’t help that most infrastructure here is markedly different than that of the Midwest: grid-like streets have been replaced by gently curving tree-lined roads that don’t allow you to see more than a quarter mile down the road. If my car’s GPS could talk, it would probably be muttering about all the overtime.

As my wife and I navigate this new landscape, I could not help but draw comparisons to open source communities. When someone moves to a new (to them) project, what things are acting as barriers for them to get more involved sooner? As community managers, we often focus on onboarding as being a large responsibility on the part of the project. But do we think about what expectations a new member of the community might be bringing with them?

Consider: when someone enters a new community, they haven't been living in a vacuum. Like a van full of cardboard boxes, they are bringing their own experiences with them, and they are going to instinctively seek out the parts of the new community that will be most familiar to them. We are all, after all, creatures of habit, because pattern-discovery and -matching are hard-wired into our brains. 

Thus, a new member of any project is going to automatically observe things in the new community and make internal comparisons to something else in their prior experience: another community’s way of doing things or something they learned at a previous job, for instance. This is not always a negative comparison, mind you; it can go either way. But the comparison will be made, as newcomers are going to try to reassess this new “home” in terms of that which is familiar.

Clearly it is not possible to tailor-make a project’s community to match all new members' expectations. Participants should ultimately learn to understand the new environment, no matter how much they want to make it like something more convenient for them. Change can come, of course, but usually later: it’s very hard to change what you don’t know.

Community managers can help new project members find important aspects of the project faster. By putting up “sign posts” in the community as part of the onboarding process, you can help direct newcomers to the parts of the project that are important to the project’s operations and enable them to quickly see for themselves how your community works.

The signposts don’t have to be everywhere: what’s important to one community member may not be as high a priority to others, or you. Like moving to a new town: some may look for groceries, parks, and a bank first. Others may seek schools. In this house, it’s groceries, gas, and pizza. In an open source project, there are some relatively universal things you should highlight.

• How to use it. Where does one go to get the thing the project is making, and start using it?

• How to learn. Where is the documentation or training materials to learn how to use the project?

• How to contribute. How does one start building upon the project?

If that looks like the three principles of onboarding, that’s certainly no accident. These aspects of a community should always be highlighted. In more detail, you should look at your project with a critical eye and determine what elements of the community are deliberately different. Maybe, for instance, your project uses SVN as a version management tool, with which new contributors might not be familiar. Or your community has a monthly online social gathering... anything that you feel makes your community unique in its operations should be highlighted.

Transitions are always going to be sources of turbulence for folks. As community managers, we should seek to calm that turbulence as much as possible.