Set that your project make aeh succeed
You don launch your project, you dey spread the word, and people dey check am out. Correct! Now, how you wan make them stick around?
One welcoming community na one investment into your project’s future and reputation. If your project just dey start to see its first contributions, make you start by dey give early contributors one positive experience, and make you dey easy for them to dey come back.
Make people dey feel welcome
One way to think about your project’s community na through wetin @MikeMcQuaid call the contributor funnel:
As you dey build your community, consider how person wey dey the top of the funnel (potential user) fit possibly waka reach the bottom (active maintainer). Your koko na to reduce any wahala for each stage of the contributor experience. Na when people fit see better results without too much stress, them go feel encouraged to do more.
Start with your documentation:
- Make am easy for person to use your project. One friendly README and clear code examples fit make am easier for anybody wey land for your project to begin.
- Explain contribution make aeh clear, using your CONTRIBUTING file and make sure say your issues dey up-to-date.
- Good first issues: To helep tear rubber contributors start, think am say labeling issues wey dey simple for beginners to handle. GitHub go show these issues for different places for the platform, e go increase useful contributions and reduce friction for people wey wan handle issues wey too hard for their level.
GitHub’s 2017 Open Source Survey talk say incomplete or confusing documentation na the biggest problem wey open source users dey face. Good documentation go invite people to interact with your project. E fit happen say one person go open an issue or pull request. Use these interactions as opportunities to waka them down the funnel.
- When new person land for your project, thank them for their interest! E fit just take one bad experience for person to no wan come back again.
- Be responsive. If you no respond to their issue for one month, e possible say them don forget your project.
- Open mind about the types of contributions wey you go accept. Many contributors start with one bug report or one small fix. Many ways dey to contribute to one project. Make people fit help the way wey them wan help.
- If one person submit one contribution wey you no gree with, thank them for their idea and explain why e no follow your project scope, and you fit add link to the relevant documentation wey you get.
Most open source contributors na “casual contributors”: people wey only occasionally contribute to one project. One casual contributor fit no get time to sabi everything about your project, so your work na to make am easy for them to contribute.
Encouraging other contributors na one investment in yourself, too. When you empower your biggest fans to run with the work wey dem dey passionate about, e go reduce the pressure to dey do everything yourself.
Make you write everything for document
When you start one new project, e fit be like say e natural to dey keep your work private. But open source projects dey flourish when you document your process for public.
When you write things down, more people fit participate at every stage of the way. You fit get help for something wey you never sabi say you need am.
To write things down no mean only technical documentation. Anytime you feel the urge to write something down or privately discuss your project, ask yourself whether you fit make am public.
Make you transparent about your project’s roadmap, the types of contributions wey you dey look for, how contributions dey review, or why you make certain decisions.
If you see say many people dey run into the same problem, make you document the answers for the README.
For meetings, consider say make you publish your notes or key points for one relevant issue. The feedback wey you go get from this level of transparency fit surprise you.
To document everything apply to the work wey you dey do, too. If you dey work on one substantial update for your project, make you put am for one pull request and mark am as one work in progress (WIP). So, other people fit dey involved for the process from the beginning.
Be responsive
As you promote your project, people fit get feedback for you. Them fit get questions about how things dey work, or them fit need help to begin.
Try to dey responsive when person open one issue, submit one pull request, or ask question about your project. When you respond quick, people go feel say them dey part of one discussion, and them go dey more enthusiastic about participation.
Even if you no fit review the request immediately, acknowledge am early to help increase engagement. @tdreyno respond to one pull request for Middleman like this:
A Mozilla study talk say if dem review code within 48 hours, plenty contributors dey return and contribute again.
Any talku-talku about your project fit dey happen for other places online like Stack Overflow, Twitter, or Reddit. You fit set notification for some of these places so dem go alert you if person talk about your project.
Make you create one place where your community go gather
E get two reason why you suppose create community place. The first reason na for dem, e go helep dem know each other. People wey get common interest must dey find place wey dem go yan about am. And when communication dey public and easy to reach, anybody fit read past messages make e understand wetin dey happen and fit join the talk. The second reason na for you. If you no create public place for people to discuss your project, dem fit contact you directly. For beginning e fit dey easy for you to respond to private messages “just this once”. But as time dey go, especially if your project dey popular, you go dey tire. No gree make you dey communicate with people about your project for private. Instead, direct dem go one public place.
Public communication fit be as simple as directing people make dem go open issue instead of sending mail give you directly or make dem comment for your blog. You fit also create mailing list, or make you create Twitter account, Slack, or IRC channel for people to talk about your project. Or you fit even try all of them!
[Kubernetes kops] (https://github.com/kubernetes/kops#getting-involved) “Kubernetes kops dey set time every other week make dem helep community members:
Kops still get time wey dem set aside every other week to offer guidance and help to the community. Kops maintainers don agree to set time wey dem go use work with newcomers, helep with PRs, and yan about new features.
Notable exceptions to public communication be: 1) security issues and 2) sensitive code of conduct violations. You suppose always get one way wey people fit report these issues for private. If you no wan use your personal email, set up one email wey dem go use just for this.
Make your community dey climb
Communities get power. That power fit be good thing or bad thing, depending on how you use am. As your project community dey grow, there dey ways wey you fit use make am be force for building, no be destruction.
No dey tolerate bad actors
Any popular project go always attract people wey go dey do bad things instead of helep. Dem fit dey start arguments wey no dey necessary, dey quarrel on top small-small things, or dey bully others.
Do your best make you get zero-tolerance policy for these kind people. If you no fit control dem, these bad people fit dey make others for your community no dey comfortable. Dem fit even run.
Regular debates on top small-small parts of your project dey distract others, and even you, from focusing on important work. New people wey show for your project fit see these arguments and no wan join.
Any time you see bad behavior wey dey happen for your project, yan am out for public. Explain, with kind but firm words, why their behavior no good. If the problem no stop, you fit need tell them make dem waka. Your code of conduct fit be useful guide for these talks.
Meet contributors where dem dey
Good documentation dey very important as your community dey grow. People wey no dey familiar with your project fit read your documentation make dem quickly understand wetin dey happen.
In your CONTRIBUTING file, tell new contributors explicitly how dem go take start. You fit even make one special section for this purpose. Django, for example, get one special landing page to welcome new contributors.
For your issue queue, label bugs wey dey suitable for different types of contributors, like “first timers only”, “good first issue”, or “documentation”. These labels These labels go helep someone wey dey new to your project to easily look your issues and take start.
Use your documentation to helep people feel welcome at every step.
For example, here’s how Rubinius starts its contributing guide:
You no go fit talk with most people wey go show for your project. Some people fit come helep you wey you no go sabi because dem feel say dem dey intimidated or dem no sabi where to take start. Even few kind words fit helep make person no commot for your project for frustration.
Share the person waeh get your project
People dey ginger to yan-kick for projects when dem feel like dem get sense of ownership. E no mean say you go come give dem your project vision or gree accept contributions wey you no want. But as you dey respect and appreciate other people efforts, e go make dem dey yan-kick.
Try look for ways wey you fit share this ownership with your community as much as possible. Some yeye ideas wey you fit try include:
- No dey hurry to fix small-small (non-serious) wahala. Instead, use am as chance to bring new contributors or show person way wan yan-kick. E fit look strange at first, but as time go dey, your investment go bring profit. For example, @michaeljoseph tell one person say make e submit pull request for Cookiecutter issue for down, instead of make e fix am himself.
-
Start CONTRIBUTORS or AUTHORS file for your project wey go list everybody wey don yan-kick for your project, like Sinatra do.
-
If your community don shapely well-well, send newsletter or write blog post to appreciate the people wey don yan-kick. Rust’s This Week in Rust and Hoodie’s Shoutouts na two examples wey dey good.
-
Give every contributor access to commit. @felixge see say this one dey ginger people, e make dem dey shine their patches more, and e even find new maintainers for projects wey e never dey touch for long.
-
If your project dey on GitHub, move your project from your personal account go Organization and add at least one backup admin. Organizations dey make am easy to work with external people.
The fact na say most projects get only one or two maintainers wey dey do plenty work. As your project dey grow or your community dey big pass, e go dey easy to find help.
Even if you no fit always find person to answer the call, once you put signal for there, e dey increase chance say other people go waka come yan-kick. The earlier you start, the better for you, because e go make people waka come fast-fast.
Na for Welcoming Communities, @gr2m yarn say e dey for your best interest to find contributors wey sabi and enjoy to do the things wey you no sabi. If you like code but e no dey easy for you to answer issues, try find people for your community wey sabi, make dem handle am.
Settling Wahala
As your project dey begin, e dey easy to make major decisions. When you wan do something, e fit be like breeze, you go just do am.
As your project dey popular, more people go dey chook eye for the decisions wey you dey take. Even if you no get big community of contributors, if your project get many users, people go wan add their mouth for the decisions or raise their own issues.
Aside small-small issues wey e clear say your community go fit resolve, sometimes you fit see say one issue dey tough small-small.
Arrange everything make kindness dey
When your community dey tackle one yeye issue, tempers fit dey rise. People fit vex or feel frustrated and dem fit they chook mouth for each other or for your matter.
Your work as maintainer na to make sure say these situations no go high. Even if you get strong opinion on top the matter, try play moderator or facilitator role, no just enter the matter dey force your views. If person no dey polite or e dey use mouth scatter discussions, take action immediately to make sure say discussions dey civil and productive.
Other people dey look you for guidance. Set example wey go make sense. You fit still yan your disappointment, sorrow or concern, but do am calmly.
Make your head nor dey hot e nor easy, but as you set good example, e go make your community strong. The internet dey thank you.
Treat README like say na constitution
Your README no be only set of instructions. E also na place to yan about your goals, product vision, and roadmap. If people dey focus too much on top argument about one particular feature, e fit help if you go back your README, talk about the higher vision of your project. To focus on your README go even make the matter no dey personal, so that you go fit yan-kick with sense.
Make we focus for the journey, nor be the destination
Some projects dey use voting process to take make major decisions. E fit look sensible for eye at first, but voting dey show say them dey find ‘answer,’ instead of say them dey listen to each other concerns.
Voting fit turn political, where people for the community go dey fear say them go gree do favors for each other or vote in one particular way. Nor be everybody go fit vote, whether e na the silent majority for your community or people wey dey use your project wey nor know say vote dey happen.
Sometimes, voting na necessary way to take settle wahala. But as much as you fit, try dey emphasize “consensus seeking” instead of consensus.
For one consensus seeking process, community members go yan about major concerns until them believe say their talk don dey enough. When only small-small concerns still dey, the community go dey go front. “Consensus seeking” no dey expect say the community go reach perfect answer. Instead, e dey focus on listening and discussion.
Even if you nor actually use consensus seeking process, as a project maintainer, e dey important make people know say you dey hear them. To show say you dey hear people and you dey ready to settle their wahala, e dey help to cool down tense situations. After that, follow your words with actions.
Don’t dey rush make you take decision just because you wan find solution. Try make everybody feel say dem don dey hear and all information dey public before you fit find solution.
Make we dey yan for action
Discussion dey important, but difference dey between productive and unproductive talks.
Encourage discussion as long as e dey carry us close to solution. If e clear say the talk dey delay or dem dey yan out of the matter or e dey like say dem dey yan personal talk, or people dey yan yeye about small details, e dey time to stop am.
If you allow this kind talk to continue, e no go only bad for the issue wey dey ground, e go dey bad for the health of your community. E go show say this kind talk na normal thing wey them dey allow or even dey encourage, and e fit discourage people from raising or settling future issues.
For every talk wey you talk or other people talk, ask yourself, _“How this one wan carry us closer to solution?
If the talk dey scatter, make you ask the group, “Which steps we wan take next?” to refocus the discussion.
If the talk clear nor dey waka, e nor get clear action to take, or the right action don already happen, close the issue and yan why you close am.
Choose your battles with sense
Context dey important. Think about the people wey dey the discussion and how them represent the rest of the community.
Na all the community dey vex or even follow for this issue? Or na just one person wey wan dey find trouble? No forget say you suppose consider your silent community members, nor be only the people wey dey yan.
If the issue nor dey show the real needs of your community, you fit just gree say the concerns of few people matter. If this one na issue wey dey always come up and nor dey get clear solution, tell them say make them check discussions wey dem don already talk about the matter before and close the discussion.
Identify person or group wey fit be community tiebreaker
With correct attitude and clear communication, many difficult situations fit dey easy to settle. But even for productive talk, e fit still dey difference for opinion on how to dey move front. For this kind situation, identify one person or group of people wey fit help settle the wahala.
One tiebreaker fit be the main person wey dey control the project, or e fit be small group of people wey fit make decision based on voting. E good make you don already identify tiebreaker and the process for GOVERNANCE file before e go happen.
Your tiebreaker suppose be last option. Issues wey dey cause fight for community dey make the community fit grow and learn. Embrace the opportunity and use collaborative process to find solution where you fit.
Community na the ❤️ of open source
Healthy and vibrant communities na the engine wey dey fuel the plenty hours wey dem spend for open source every week. Many contributors dey point to other people as the reason why dem dey work - or nor dey work - for open source. As you sabi tap into that power constructively, you go fit help person somewhere get unforgettable open source experience.
