If you want new people to contribute to your open source project, make it easy for them, not hard. Give them positive feedback and provide some guidance in your code base. Deliberately leave some easy to solve but less critical tasks for them to allow for achievable motivating success. Think gaming where you need an easy start to stick to the game before entering the hard, demanding levels.
At this years FrOSCon 8 Isabel Drost-Fromm (also on (GitHub and Twitter) held a talk labeled „Talking people into creating patches“. There were some maintainers of open source projects in the room, and many of them expressed they lack a sufficient number of contributors for their projects.
In the Q&A session i took the microphone and shared my view of a willing, but mostly unsuccessful contributor to projects. My observations seemed to be received well by the audience, so i want to keep hold of them here:
Do not accidently overlook contributions
Put extra into effort into not accidently overlooking even small contributions, as this might frustrate the new contributors, driving them away from your project forever.
In a small project i once saw a nice, well done pull request on GitHub was left unanswered. Not rejected, not due for improvement, simply ignored. I needed that special feature in there for my own work, so i pressed the maintainer to take the pull request or i would fork his project and continue my work in my own fork. All in a sudden accepting the pull request was no problem. Do not do this, unless there is a real problem with the pull request. Explain why.
Do not use the issue tracker as your personal ToDo-list — it is public!
Especially in projects with a small and closed group of contributors, often the public issue list looks like a personal ToDo-list for the guy that wrote the issue: just the subject line, no details, no context and no clear goal understandable to someone getting freshly into the project. Always write your issues such that anyone (not only you) can understand what should be done, and perhaps even what should be the preferred way to solve the issue. Writing good issue descriptions needs more knowledge of the code than resolving such a well-written issue, and in bad cases, may take as much time.
Deliberately keep some low hanging fruit for the newcomers
Keep some easy, manageable tasks for the new guys in your open issues, even if you as an experienced guy could do them in minutes. Best for that are the non-critical tasks with a clear scope. These can be the breadcrumbs that build self confidence in your new contributor and motivate them to tackle the harder tasks while they follow you into the thicket of your code base. You as the experienced core developer should crack the hard nuts in your issue tracker, not the trivial ones.
Write some high-level-guide describing the structure of your project
If your code base structure exceeds triviality (which it quickly does, especially with Java projects), provide new contributors a high-level overview over your code structure and architecture (every piece of software has an architecture, whether you are aware of it or not). Think of it as an
README not for the user of but for the contributor to your project. Make them comfortable with some of the previously unwritten rules in your project before problems arise, and