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.
저자 소개
Brian Proffitt is Senior Manager, Community Outreach within Red Hat's Open Source Program Office, focusing on enablement, community metrics and foundation and trade organization relationships. Brian's experience with community management includes knowledge of community onboarding, community health and business alignment. Prior to joining Red Hat in 2013, he was a technology journalist with a focus on Linux and open source, and the author of 22 consumer technology books.
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.