In many cases the only person who can answer a specific question about your project is you. Try to be responsive about issues/pr's. If you're not available to do it or fix it you can always encourage people to fix it themselves, pointing to possible solution.
Consider using Gitter or Slack to keep in touch with contributors and users. You could also offer guidance and help around troubleshooting issues.
When trying to contribute to a project for the first time what takes the longest is not doing the actual change but getting familiar with how the project works.
Spending some additional time on making the documentation can go a long way. If you're not sure how to start here's a beginners guide to writing documentation.
Larger projects can also benefit from additional high-level developer documentation describing how the pieces fit together.
It's an often forgotten file which contains guidelines about how and what to contribute. Being supported by GitHub it will show up when creating new issue/PR. See an example file.
Don't forget to mention it in your readme too. If you want to spread more awareness you could use this snippet which links to this guide.
Remember to add example use cases to your readme. Seeing how the project can be used helps people understand how it is supposed to work.
If your project is supposed to be used as a library/dependency create some demos that will show how it could be used.
Tests are a great way to improve your project's quality. Combined with linting helps contributors to quickly see if their change had some unintentional effects and if the code aligns with general style of the project.
Continuous integration tools like Travis CI or Circle CI will automatically report any problems like this.
Different tasks require different amounts of commitment. Try to select a couple of small ones allowing contributors to have a quick start and get familiar with the internals.
Joining up-for-grabs,
labeling issues for first timers with up-for-grabs
and difficulty level could be a great start.
Try to avoid jargon, buzzwords and overly complicated explanations. Using simple language, being friendly and open creates a welcoming environment which helps create a healthy community.
Think about implementing and enforcing Code of Conduct. Being clear that hostile and prejudice behaviour will not be tolerated will enable a safe and more open collaboration.
If you know other ways to embrace contributions or want to discuss current ones, feel free to go through GitHub Issue.
Also thank you for all the people who try to make Open Source even more open! You rock!
Icons by: Anton Scherbik Till Teenck Milky Lucas Rod Takao Umehara joe pictos Julien Deveaux