Stormy, at OpenSource.com, recently asked the question “What are 10 steps to keeping new contributors once you have their attention”

I’m not sure I have 10, but here’s what I’d say:

Celebrate their contribution, loudly and publicly

People like to be noticed, and they like to be thanked. Tell them that you noticed their contribution by telling the whole world about what they did.

There’s a number of ways to do this, from tweeting every first contribution, to including a Thanks section in your monthly newsletter, to doing a weekly blog post that lists new contributors for that week. Whichever approach you take, make sure that you personally send them a message telling them about it, rather than just hoping that they notice it.

If you have very few new contributors every week/month, then take the time to describe what the new contributor did. If you have dozens every time, this can be more of a challenge, but sending them a personal note is still a very critical part of the process if you want them to stick around.

Give them the keys

A lot of people in open source think that everyone should have to earn their place on the contributor list, by consistent, high-quality contributions over a long period of time.

I’m at the other end of the spectrum. I think you should hand out committer rights like candy. If someone shows initiative and contributes once, give them the opportunity to contribute again, immediately, with no barrier to entry.

What’s the worst that can happen? You have to revert a patch. This is why you have revision control.

So, give them the keys on day one. But there’s a caveat here, which is the next item on my list:

Give constructive criticism

Nobody likes a patronizing pat on the head. Give constructive feedback. After thanking them, tell them patiently and kindly what they can improve. This shows that you consider them to be a contributor to a serious project, and not merely a statistic to report to your boss.

If you have a style guide, and they didn’t live up to it, point them to it, gently and kindly, and give them specific pointers on what they need to improve.

Don’t be one of those jerks that throws it back in their face with a nasty remark. That will guarantee that they won’t come back. Remember that your goal is to retain new contributors, and train them up in the way that your project operates, not merely to act as a filter to keep out unfavorable contributions.

Ask them to do it again, with a specific request

People like to be asked. Asking someone, personally, to do a particular task, is much more effective than a shotgun “Hey, can someone …” sent out to an anonymous faceless mob on a mailing list.

Once someone has contributed something, that’s your opportunity to say, “Hey, I notice that you have some interest in the WhizBang feature, and Ticket 31245 is about that, too. Maybe you could take a look?”

Ask them to write about it

The new contributor experience is a rare and valuable thing. You don’t know what it’s like any more. You remember bits of it, but mostly you’ve forgotten, and become jaded with your second, third, and 700th contribution.

Encourage this new contributor to write about their experience. What was too hard. What was fun. What was unexpected, frightening, exciting. Who helped them. Who got in their way.

These are hugely valuable data points for your project. And they are also a great way to tell this new contributor that their input is valuable, and that you’re trying to make your project more welcoming.

And, of course, once they have written about it, share it with the developer community, along with the name of the contributor, and say, here are some ways maybe we can make this better for the next person.

Point them to the documentation

You have docs, and then you have hidden docs, and then you have the stuff that “everybody knows”. Steer this new contributor to the docs, and take the opportunity to turn the other two categories into actual docs.

Some of this will come out of the blog posts that these new contributors write. Some you will need to write yourself, based on their feedback of the new contributor experience.

This is tedious, but, remember, you’re making an investment in the next time. The better you make this process, the easier it will be for the next person, and the sooner you can pass this part of the job on to someone else.

Ask them to mentor the next new contributor

Ask them to turn that first-timer experience into mentoring another first-timer, as soon as possible. They’ll have the recent experience. They’ll know the potholes that you have long since learned to steer around. They’ll know which people in the community are helpful, and which ones are jerks, who you’ve long ago dismissed as “Oh, that’s just how Larry is.”