Your Red Hat account gives you access to your member profile and preferences, and the following services based on your customer status:
Not registered yet? Here are a few reasons why you should be:
- Browse Knowledgebase articles, manage support cases and subscriptions, download updates, and more from one place.
- View users in your organization, and edit their account information, preferences, and permissions.
- Manage your Red Hat certifications, view exam history, and download certification-related logos and documents.
Your Red Hat account gives you access to your member profile, preferences, and other services depending on your customer status.
For your security, if you're on a public computer and have finished using your Red Hat services, please be sure to log out.Log out
This is a question community managers hear a lot. Everyone wants to grow their project and we all want to hear what worked (or didn't) for others. One of the benefits I have by working for Red Hat is being part of a large community of community managers and community oriented people. Stormy Peters put this question to that group last year:
We are all working to grow the communities around our projects, in particular diverse communities (diversity of company, gender, geography, etc.). What's the single best tip you've gotten for attracting new contributors? Who gave it to you? Or, alternatively, what's the single thing that's made the most impact on attracting new contributors to your project?
She got a lot of great answers, some of which I've collected here.
"There is no single best tip for attracting new contributors," said Amye Scavarda, Community Manager for Gluster. She related that the focus in her community has been on continuing to improve the test suite for their code base. This way new patches don't get slowed down waiting on manual testing. However, this has to be balanced carefully against the idea new contributor gateway that testing can be. It's the balance between "automate all the things" and "automate just enough to get out of your own way." She learned this lesson while working with the Drupal community. When they implemented a full automated testing suite they noticed a dip in their number of contributors as testing was an onboarding path for new contributors.
Josh Berkus, community manager for Red Hat's participation in Kubernetes, points out that you have to "make it obvious how to contribute." Rich Bowen, CentOS Community Manager believes that this goes hand-in-hand with ensuring that there are specific tasks for beginners to work on, for example, like these pages from the RDO Project and Apache. "[This] tells them that they are empowered to participate, and it shows them where to get started." As each task probably has a person associated with it, this also provides a coach or mentor to help someone get started. He added that in his experience, "a lot of people want to be involved, but are just waiting to be asked."
Onboarding processes are critical. I've found that in the Fedora Project some of our most successful groups, as far as we can estimate, have a mentoring process in place. We are trying to build on that and make it easier for Fedora subprojects to create onboarding program and mentoring programs. These programs are much more effective, Brian Proffitt, Principal Community Analyst for Open Source and Standards team, points out if you push onboarding in a consistent way on the project's website. This also means that "we need to make sure project software is easy to understand, easy to find, and easy to start using."
Leslie Hinson, with the Patternfly project, reiterated the need for good onboarding experiences. "PatternFly has recently put a ton of effort into trying to provide a good onboarding experience for designers (especially since they are not accustomed to GitHub)." They created a contributing.md on the PatternFly Design repo to onboard design contributors as well as a wiki and YouTube tutorials to explain the use of GitHub. They go out of their way to welcome new contributors and ensure they know the proper communication channels to use for questions. Jim Perrin, with the CentOS project, reminds us that "no one is a small fish in the community. Even if you're chasing larger groups of users/contributors, be sure to take the time to talk to everyone and make them feel that they matter."
Karsten Wade, Community Architect, notes that we need to make sure that everyone is acknowledged and "shown a pathway toward more contribution when they are ready." This allows people to grow at their own pace. Steven Ellis, a Senior Solution Architect. He has seen people struggle to engage with an upstream. "Even something as simple as raising a bug report can vary from project to project. If I could get a couple of my partners to both raise and fix (pull request etc) some of their upstream bugs, even just around documentation, it would kickstart the upstream contribution process."
Dave Neary, community manager for the Eclipse Che project, brings it back to the people. "Newcomers look for 'people like themselves' to approach when in an unfamiliar environment. The more diverse the welcoming committee, the more welcome people will feel."
What are your ideas around growing the contributor base of your project? How did your project get your first ten external contributors?